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

Caio Marcelo de Oliveira Filho caio.oliveira at intel.com
Fri Jun 29 00:44:07 UTC 2018


> > 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.


More information about the mesa-dev mailing list