<div dir="ltr"><div class="gmail_default" style>On Thu, Jan 10, 2013 at 12:58 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank" class="cremed">clattner@apple.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Jan 9, 2013, at 10:58 PM, Andrew Trick <<a href="mailto:atrick@apple.com" class="cremed">atrick@apple.com</a>> wrote:<br>
<br>
><br>
> On Jan 7, 2013, at 4:53 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="cremed">clattner@apple.com</a>> wrote:<br>
><br>
>> On Jan 7, 2013, at 6:41 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="cremed">chandlerc@gmail.com</a>> wrote:<br>
>>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=171735&view=rev" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project?rev=171735&view=rev</a><br>
>>> Log:<br>
>>> Switch the SCEV expander and LoopStrengthReduce to use<br>
>>> TargetTransformInfo rather than TargetLowering, removing one of the<br>
>>> primary instances of the layering violation of Transforms depending<br>
>>> directly on Target.<br>
>><br>
>> This is soo great!<br>
>><br>
>>> be created by the backend. No longer is this true. LSR is now just<br>
>>> a normal pass and we should probably lift the creation of LSR out of<br>
>>> lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done<br>
>><br>
>> 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.<br>

><br>
> 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.<br>
<br>
</div>You're not wrong, that's what I was trying to get at. :)<br>
<div class="im"><br>
> In particular, vectorization and partial unrolling. Especially if a preloop is inserted for any reason.<br>
<br>
</div>I hadn't considered vectorization as being destructive, but I guess that it is, particularly if we're doing it as part of LTO.<br>
<div class="im"><br>
> Can we just tell the PassManagerBuilder that we're not ready to lower loops yet?<br>
<br>
</div>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?</blockquote>
<div><br></div><div style>Everything you guys are saying is exactly in line with my thinking.</div><div style><br></div><div style>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 <br>
</div></div></div></div>