[Mesa-dev] [PATCH 03/10] glsl: don't let an 'if' then-branch kill copy propagation for else-branch

[Caio Marcelo de Oliveira Filho]

Hi,

> > The hurt instruction count is caused because the extra propagation
> > causes an input variable to be read from two branches of an
> > if (load_input intrinsic in NIR). Depending on the complexity of each
> > branch this might be a win or not in terms of cycles.
> 
> I just sent out a patch (nir/opt_peephole_select: Don't try to remove
> flow control around indirect loads) that deals with a similar sort of
> thing.  Were the cases you observed also indirect loads?

Thanks for this comment. The cases in question look like:

      (declare (location=... shader_in ) vec4 aaaa)

      ...

      (declare () vec4 bbbb)
      (assign  (xyzw) (var_ref bbbb)  (var_ref aaaa) ) 

Later assignments using 'bbbb' get 'aaaa' instead.


> Maybe we
> should add those to the class of things that don't get copy propagated

I thought of that, but my conclusion was that the propagation can
actually give us wins if the uses are both inside nested branches in
the two toplevel branches. I might be wrong, but the resulting NIR
also looks "resolvable", so the outcome here might be find the right
pass in NIR to improve.


Thanks,
Caio