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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
