On 03/20/2015 02:51 PM, Matt Turner wrote: > On Fri, Mar 20, 2015 at 1:58 PM, Ian Romanick <i...@freedesktop.org> wrote: >> From: Ian Romanick <ian.d.roman...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
