<div dir="ltr"><div class="gmail_extra">I haven't been following this thread either. I am now.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Generally, design discussions would be better served to be on the dev list.</div>
<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 1:52 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank" class="cremed">nlewycky@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>As Eric suggested, I was surprised to discover we have a -emit-llvm flag, then more surprised that it didn't bother to pass the right linker flags when linking. I think I called it "a broken copy of -flto", arguing that we should delete it entirely, in favour of -flto.</div>


<div><br></div><div>As for telling the compiler "I want to build with LTO", we already have -O4 which is presently equivalent to -O3 -flto. Let's keep that? In the future, -O4 should select the pre-IPO optimizations. (I would also like a "-Olto" flag specifically so that I can select the pre-IPO optimization stack, even if I'm generating native code directly, for debugging and benchmarking and also to keep separate the concerns of selecting an optz'n stack and selecting the output format.)</div>


<div><br></div><div>I won't block a patch that changes/removes -flto, but my fingers will still be typing it for years to come. I don't want it, but I could live with it.</div></blockquote></div><br>I think there is no path forward for supporting LTO on the commandline that allows all of the existing users to continue using the command lines they have. We should abandon that hope.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">First, -O4 is a *very* bad name. LTO is not about how hard we optimize but about *where* we optimize. I sent out a proposal to eventually make -ON saturate at 3 (possibly with a warning) and there was no real arguments against this a long time ago. I still think that is the correct design there.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As Shuxin said, we have two *overlapping* use cases:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) I want to do LTO.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">2) I want to get the IR out for some development purpose (I do not care what optimization model is being requested).</div><div class="gmail_extra"><br></div><div class="gmail_extra">The only sensible flag for requesting LTO is '-flto'. Requesting LTO is the only sensible use of that flag.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If you want IR to debug something or see the IR, you don't want to change the compilation or optimization model, you just want to get IR. This is exactly what '-emit-llvm' does and should provide.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If people are surprised by the fact that '-emit-llvm' happens to be a no-op when using '-flto', they will learn something about or LTO.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">If people are surprised that passing '-flto' changes the optimization strategy to be better aligned with running the optimizer at link time, they have gotten what they asked for and need to change what they are asking for.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>