[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'

[Andrew Trick]

On Apr 26, 2013, at 7:32 AM, Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com> wrote:

> Hi Andrew, Shuxin,
> 
> Thanks for the explanation about 'Reassociate'.
> 
> The problem is indeed that one of the variables, becomes loop invariant after
> some of the loop transformations.

I imagine LoopSimplify is enough to fix your loop invariant phi so it's an obvious constant. At least obvious enough for InstCombine to remove it from the loop. Unless LoopSimplify is being defeated by an indirect branch, which is just silly in the case of a loop where the back edge is not indirect.

>> -----Original Message-----
>> From: Andrew Trick [mailto:atrick at apple.com]
> [...]
>> Right. Reassociate ranks expressions by their order in the IR, so shouldn't
>> make matters worse, but it doesn't know about loops so can't expose more
>> of these opportunities AFAIK.
>> 
>> Jeroen, it may be worth filing a bug. I'm not sure why LSR isn't handling it
>> later.
>> 
>> For cases that LSR doesn't handle, we've been wanting an MI reassociate
>> pass in the backend anyway to expose ILP. That could clean up cases like this
>> when it's actually on the critical path and we don't mind the regpressure.
>> 
> 
> I inserted a small optimization pass to recognize and fix this exact sequence.
> This did indeed improve the performance (good ;) ), but not to the amount that I hoped..
> I'll try to come up with a reduced file that shows this problem and file a bugreport for it.

A bug would be nice. It maybe something to consider if we decide to reorder passes.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130429/bf035ec5/attachment.html>