[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/

[Chandler Carruth]

On Thu, Jan 10, 2013 at 12:58 PM, Chris Lattner <clattner at apple.com> wrote:

>
> 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?


Everything you guys are saying is exactly in line with my thinking.

I've got a design proposal that should be migrating from the whiteboard
here where Dan and I sketched it out to an RFC email Real Soon Now, but I
wanted to clarify that we're in (violent?) agreement. =D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130110/871c35df/attachment.html>