[llvm] r229419 - Run LICM as part of the cleanup phase from the scalar optimizer.

[Chandler Carruth via llvm-commits]

Hi James and Hal, any update on this?

Last state I recall is that SimplifyCFG is partitioning the loop pass
pipeline in two preventing LICM from running after LoopUnroll in the
inside-out pass ordering.

It'd be really good to work on adding the missing functionality to
LoopSimplifyCFG so we can switch to that and get a single loop pipeline.
(We should also add other loop pass harnesses like LoopInstCombine
necessary to expose the invariant code here).

-Chandler

On Fri, Feb 19, 2016 at 6:06 AM Chandler Carruth <chandlerc at gmail.com>
wrote:

> (Sorry for repeat mail for some, forgot to fix the mailing list address)
>
> On Mon, Feb 16, 2015 at 11:04 AM James Molloy <james.molloy at arm.com>
> wrote:
>
>> Author: jamesm
>> Date: Mon Feb 16 12:59:54 2015
>> New Revision: 229419
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=229419&view=rev
>> Log:
>> Run LICM as part of the cleanup phase from the scalar optimizer.
>>
>> Things like LoopUnrolling can produce loop invariant values - make sure
>> we pick them up.
>>
>
> Sorry for the commit archaeology, but this patch really doesn't make sense
> to me.
>
> In order to do this, we have to re-canonicalize all the loops and build a
> new loop pass manager to do LICM and nothing other than LICM. Notably, we
> don't do any of the other obvious loop passes afterward like loop deletion.
>
> The explanation also doesn't completely make sense to me because of how
> the loop pass pipeline works. When we unroll an inner loop, we should start
> the loop pass pipeline again on the outer loop, which should allow LICM to
> see the suddenly invariant values.
>
> I think that you may have been trying to fix symptoms of the loop pass
> pipeline being split up by function passes as described in PR24804. If
> that's the case, the fix really isn't to add a late LICM run, but to get
> the loop pass pipeline to be cohesive and complete.
>
> And if we need to have two loop pass pipelines, we really need each of
> them to be "complete" loop optimization pipelines, including rotation,
> LICM, deletion, and unrolling (likely in that exact order).
>
> What do folks think? I'm about to land a test that should also make it
> more clear what the structure of the pass pipeline happens to be.
> Enhancements there would be welcome.
>
> Also, it would be great to have functional test cases for what this
> catches James... Is there any hope of crafting one?
>
> -Chandler
>
>
>>
>> Modified:
>>     llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp
>>
>> Modified: llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp?rev=229419&r1=229418&r2=229419&view=diff
>>
>> ==============================================================================
>> --- llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp (original)
>> +++ llvm/trunk/lib/Transforms/IPO/PassManagerBuilder.cpp Mon Feb 16
>> 12:59:54 2015
>> @@ -259,6 +259,7 @@ void PassManagerBuilder::populateModuleP
>>    MPM.add(createJumpThreadingPass());         // Thread jumps
>>    MPM.add(createCorrelatedValuePropagationPass());
>>    MPM.add(createDeadStoreEliminationPass());  // Delete dead stores
>> +  MPM.add(createLICMPass());
>>
>>    addExtensionsToPM(EP_ScalarOptimizerLate, MPM);
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160621/0a63ab3d/attachment.html>