[PATCH] D12345: [Reassociate]: Add intermediate subtract instructions created while negating to be redone later for more reassociate opportunities

[Daniel Berlin via llvm-commits]

On Fri, Nov 13, 2015 at 9:59 AM, Owen Anderson <resistor at mac.com> wrote:

>
> On Nov 13, 2015, at 7:58 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
>
> On Thu, Nov 12, 2015 at 11:55 PM, Owen Anderson <resistor at mac.com> wrote:
>
>> resistor added a comment.
>>
>> In http://reviews.llvm.org/D12345#288471, @dberlin wrote:
>>
>> Would it be reasonable to stage that investigation?  AFAICT the changes
>> already proposed (with Chad's comments incorporated) are a strict
>> improvement, and I at least am seeing pretty severe performance regressions
>> from their absence.  Would you be alright with going ahead and landing
>> those?
>>
>
>
> I'm not opposed, I'd like to see compile time numbers first since it
> transforms reassociate into an iterative algorithm.
>
>
> I’ll see what I can get you on that.
>
> For my use case, at least, N-ary reassociation is not really appropriate
>> as I also heavily depend on reassociation of floating point arithmetic.
>
>
> I'm not sure why these two statements go together ;-)
> What am i missing?
>
>
> N-ary reassociation depends heavily on SCEV, both in practice and
> according to Jingyue’s design doc.  SCEV does not work on floating point
> today, and it seems has an immense undertaking to get it to work on it.
>

Sure.
This is pretty easy to solve though: don't use SCEV for floating point.

The underlying algorithm is about seeing what chains operations are the
same/could be commuted.

This does not require SCEV.
(in fact, you could use GVN's infrastructure if you wnated, for example).

It uses SCEV because SCEV is great at figuring these things out for integer
operations ;-)



> —Owen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151113/1cd38dc7/attachment.html>