[llvm-commits] [llvm] r171735 - in /llvm/trunk: include/llvm/Analysis/ include/llvm/Transforms/ lib/Analysis/ lib/CodeGen/ lib/Transforms/Scalar/ test/Transforms/LoopStrengthReduce/ test/Transforms/LoopStrengthReduce/X86/

[Chris Lattner]

On Jan 9, 2013, at 10:58 PM, Andrew Trick <atrick at apple.com> wrote:

> 
> On Jan 7, 2013, at 4:53 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> On Jan 7, 2013, at 6:41 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
>>> URL: http://llvm.org/viewvc/llvm-project?rev=171735&view=rev
>>> Log:
>>> Switch the SCEV expander and LoopStrengthReduce to use
>>> TargetTransformInfo rather than TargetLowering, removing one of the
>>> primary instances of the layering violation of Transforms depending
>>> directly on Target.
>> 
>> This is soo great!
>> 
>>> be created by the backend. No longer is this true. LSR is now just
>>> a normal pass and we should probably lift the creation of LSR out of
>>> lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done
>> 
>> I'm not sure this is a good idea.  One nice thing about the current design is that "clang -emit-llvm" doesn't produce maximally target-specific code like LSR likes to produce.  We also really don't want to run LSR before LTO optimizations.
> 
> Correct me if I'm wrong. I don't think we want to run any irreversible loop optimizations that hinder subsequent loop analysis prior to LTO.

You're not wrong, that's what I was trying to get at. :)

> In particular, vectorization and partial unrolling. Especially if a preloop is inserted for any reason.

I hadn't considered vectorization as being destructive, but I guess that it is, particularly if we're doing it as part of LTO.

> Can we just tell the PassManagerBuilder that we're not ready to lower loops yet?

I'm not sure that lowering loops is the right answer.  Perhaps the "-O3" optimizer just needs a flag to know if LTO is going to be performed or not, and the relevant passes can be disabled by that?

-Chris