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

[Daniel Berlin via llvm-commits]

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:
>
> > The last status i saw was: "I'll try seeing what little needs to be done
> to
> >  converge in the couple cases that I have (one above) and a superficial
> look
> >  at why the second reassociate improves codegen."
> >
> > I saw no update on that ;-)
>
>
> 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.

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?

The difference is one of a global vs local algorithm, not of floating point
vs integer (n-ary reassociate is basically just a global version of
reassociation that makes choices with more context)

You want to move towards the global algorithm no matter what you do.


So, I'm stuck with local reassociation, and the problem described here is
> making today's LLVM integer factors worse than last year's for me.
>

I understand and am sympathetic to the second part. Still trying to
understand the first, so if you could lay it out for me, i'd appreciate it
;-)

>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D12345
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151113/01a2ec23/attachment.html>