thomashellan...@gmail.com writes: > From: Thomas Helland <thomashellan...@gmail.com> > > When writing that A || (A && B) patch some > days ago I also wrote some other patches > that have no impact on my collection of shaders. > (shader-db + Some TF2 and Portal-shaders). > No reduction in instruction count, and no > significant increase in compilation time. > > I decided to put them up here anyway, as > with your collection of shaders maybe YMMV.
I'm definitely interested in seeing our optimizer gain features like this, even if we don't have samples of code triggering them in our database yet. What we have in shader-db from real-world apps is a subset of what our compiler will encounter -- it doesn't tend to cover code by novice shader developers, nor does it cover more-complex, more-code-generated code we expect to see in the future. If the patches are cleaned up to use spaces instead of tabs, and avoid trailing whitespace, patches 1-4, 7-8, and 10 are: Reviewed-by: Eric Anholt <e...@anholt.net> For the sub case, I'm going want to disable lower_sub_to_add_neg on my hardware, since I've got SUB but no negate modifier on operands. This makes the (A - neg(B)) patch interesting to me. However, since neg(A) - B -> neg(A+B) was questioned, and it would be no change for me as well, I think we should probably drop that half. The min/max patches I'm not that interested in -- I think that class of optimization would be better handled in an pass that can track various bounds that values might have over time, rather than being a special case in algebraic.
pgpGRsZHkrClO.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
