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

[Ian Romanick]

On 03/20/2015 04:33 PM, Matt Turner wrote:
> On Fri, Mar 20, 2015 at 4:14 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> 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?
> 
> Because shaders do x * -4.0 and x * 4.0 and if we just calculate x *
> 4.0 once we can negate its use for free.

Okay... that makes sense.  That's also the case that patch 20 tries to
catch by getting the general -x*y vs. x*-y vs. -(x*y) cases.  It sounds
like the interesting experiment will be for me to compare just 18+19+20
on master with your mul-neg branch.  I may not get to that before
Monday, though.

I did this patch for much the same reason as patch 23.  There are a lot
of optimizations, including some in this series that only look for the
binary operations that they care about.  They are ignorant of neg, not,
and swizzle.  I thought adding training wheels might result in fewer
skinned knees.

>> 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.
> 
> Pushed to
> 
>    git://people.freedesktop.org/~mattst88/mesa mul-neg
>