[Mesa-dev] [PATCH 3/4] i965/fs: Optimize (gl_FrontFacing ? x : y) where x and y are ±1.0.

[Ian Romanick]

On 01/08/2015 10:59 PM, Matt Turner wrote:
> +   if ((then_rhs->is_one() || then_rhs->is_negative_one()) &&
> +       (else_rhs->is_one() || else_rhs->is_negative_one())) {
> +      assert(then_rhs->is_one() == else_rhs->is_negative_one());
> +      assert(else_rhs->is_one() == then_rhs->is_negative_one());

I'm adapting this code to do some other tricks... why did you use this
logic instead of

   if ((then_rhs->is_one() && else_rhs->is_negative_one()) ||
       (else_rhs->is_one() && then_rhs->is_negative_one())) {

It seems like that's what you actually want.

The reason I ask is in my adaptation I'm hitting some cases where the
assertion fails.  This is from code like:

  if (gl_FrontFacing)
    gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0);
  else
    gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);

After channel expressions, I end up with the equivalent of

    gl_FragColor.w = mix(1.0, 1.0, gl_FrontFacing);

I already have the obvious pass that fixes those, so it's not a huge deal.