[Mesa-dev] [PATCH 00/10] [RFC] Probably useless algebraic optimizations

[Thomas Helland]

2014-08-04 21:25 GMT+02:00 Eric Anholt <eric at anholt.net>:
> thomashelland90 at gmail.com writes:
>
>> From: Thomas Helland <thomashelland90 at 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.

This was my initial thought to.
Also, while some of these patterns are simple, and likely be spotted
by a seasoned programmer, they may end up in our tree from
other optimizations simplifying the code.

>
> 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 <eric at anholt.net>
>

I'll get these cleaned up and posted to the list again soon.
I don't have commit access, so I'll need someone to push them for me.

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

I'll rewrite this to drop the neg(A)-B part, and post it along with the rest.

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