On 03/20/2015 04:33 PM, Matt Turner wrote: > On Fri, Mar 20, 2015 at 4:14 PM, Ian Romanick <i...@freedesktop.org> wrote: >> 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? > > 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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
