[Mesa-dev] [PATCH 1/3] glsl: Propagate negates through multiplication chains.

[Matt Turner]

On Sun, Feb 22, 2015 at 2:11 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> On Wed, Feb 11, 2015 at 04:05:57PM -0800, Matt Turner wrote:
>> On Wed, Feb 11, 2015 at 3:51 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> > On 02/11/2015 02:54 PM, Matt Turner wrote:
>> >> We propagate negations to the right-most leaves of the multiplication
>> >> expression trees:
>> >>
>> >>  - mul(neg(x), neg(y)) -> mul(x, y)
>> >>  - mul(neg(x), y) -> neg(mul(x, y))
>> >>  - mul(x, neg(y)) -> neg(mul(x, y))
>> >>
>> >> total instructions in shared programs: 5943123 -> 5937229 (-0.10%)
>> >> instructions in affected programs:     868221 -> 862327 (-0.68%)
>> >> helped:                                4518
>> >> HURT:                                  356
>> >> GAINED:                                1
>> >
>> > This seems very counter intuitive.  Why does this help?  It seems like
>> > the negate modifier on the multiplication sources should be free... how
>> > do we get cheaper than free? :)
>>
>> Lots of shaders do things like var * 0.5 and var * -0.5. By making the
>> second of those -(var * 0.5) we can do the multiplication once and use
>> its result in both places, negated once.
>>
>
> Can you add this to the commit message? I had the exact same question, and this
> was the exact right answer. Also does this same thing not apply for division?

Sure.

>> I also noticed we were generating a lot more LRPs after this. I guess
>> the LRP peephole is able to recognize more stuff without some negates
>> in the way.
>>
>> If you want, I can try to take a closer look at some affected shaders
>> -- though it is kind of hard. Diff'ing GLSL IR is impossible, and even
>> if you get past the compiler_temp@ variables being renumbered it's
>> still really difficult to see what's going on.
>
> Have you already considered that this shortcircuits the next block which
> according to the comment improves the ability to fold constants, or do we end up
> through here again later? (I'm sure you're aware I know little about this code).

Yeah, we'll make it through here again, so I don't think it's any
different effectively. Also, since we're only looking for neg
expressions, the constant reassociation code wouldn't trigger anyway.

> Anyway, with the explanation it sounds reasonable to me, and since it seemed
> like nobody was actually opposed to it:
> Reviewed-by: Ben Widawsky <ben at bwidawsk.net>

Thanks!