[Mesa-dev] [PATCH 17/23] glsl: Distribute ir_unop_neg over ir_binop_mul of a constant

[Ian Romanick]

On 03/20/2015 02:51 PM, Matt Turner wrote:
> On Fri, Mar 20, 2015 at 1:58 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> From: Ian Romanick <ian.d.romanick at intel.com>
>>
>> An expression like -(x * 8) becomes (x * -8).
>>
>> Much of the hurt caused by this change appears to be from CSE not being
>> able to see (x * -8) and (x * 8) as common.  Previously -(x * 8) and (x
>> * 8) would have had a common subexpression.  Later patches address this
>> at the GLSL IR level, but additional work will be needed in NIR and the
>> i965 backend.
> 
> I've got patches that do the opposite of this: pull the negate out of
> the multiplication.

Why is pulling the negation off a constant useful?

This patch only pushes the negation onto a constant, and constant
folding will eliminate that.  There's even an assertion in the code to
be sure. :)

You have links (or a branch) to those patches?  I'd like to compare the
results with these patches.

> It was a three patch series and one of the patches was never reviewed.
> I would have just pushed them, but they hurt NIR and I haven't figured
> out how to fix that yet.

The irony being that this patch with 19 and 20 are mostly helpful with
NIR. :)

> The third patch recognizes neg(mul(...)) in the GLSL -> i965
> translators and set a source modifier to avoid an additional
> instruction from the case where we can't eliminate the negates
> entirely.
> 
> It's not just recognizing -(x * y) and (x * -y) that's problematic,
> it's (-x * y) as well. My patches handle that case too.

I think patch 19 & 20 cover all the cases for CSE.

> So I'd probably rather not take this patch.