<div dir="ltr"><div>Sorry, I totally wasn't following this thread at all. I'm assuming the goal is to clean up the flags in preparation of adding more smarts to the "we're doing LTO" case?</div><div><br>

</div>On 22 August 2013 13:10, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><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">On Thu, Aug 22, 2013 at 12:53 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
> On Thu, Aug 22, 2013 at 12:14 PM, Rafael Espíndola<br>
> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>>> Right. My comment on this change is, in essence, that people have<br>
>>> depended upon the fact that -flto does what you want -emit-llvm to do<br>
>>> for that compile line for a while. I don't think it's necessarily<br>
>>> right, but that you're going to be breaking current use.<br>
>><br>
>> So, the possible changes that people using clang will have to adapt to is<br>
>><br>
>> 1) Using -flto instead of -emit-llvm when doing an lto build.<br>
>> 2) Using -emit-llvm instead of -flto when fetching IL to be passed to<br>
>> bugpoint or similar.<br>
>><br>
>> I don't think 2 is a big concern, since it is a dev option and we<br>
>> change those as needed. Issue 1 is a bit more serious, but the change<br>
>> is really simple. The -flto option is also what gcc uses.<br>
>><br>
><br>
> The concerns I've seen are that -emit-llvm doesn't work as well as<br>
> -flto for the task of grabbing IR for any purpose. Nick is the one who<br>
> brought this up within hearing range the other day, maybe he can<br>
> explain. FWIW I only think -flto should be used to enable lto mode of<br>
> everything on the command line and not for grabbing IR at all. I.e. if<br>
> there's no link step then -flto shouldn't do anything.<br></div></blockquote><div><br></div><div>:)</div><div><br></div><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><div><br></div><div>Nick</div><div> <br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> This would be a change in behavior though.<br>
><br>
<br>
</div>Since I've obviously confused Rafael a bit as well let me attempt to<br>
be a bit more clear here:<br>
<br>
a) I'm not, ultimately, objecting to the patch pending some horrible<br>
statement from Nick.<br>
b) I agree on principle with -flto doing different things from<br>
-emit-llvm, especially as a flag to modify and change the pass<br>
manager.<br>
c) I think if we make the change on -flto != -emit-llvm then<br>
-emit-llvm should error if it isn't passed as part of -c or -S.<br>
d) We could probably use some documentation. :)<br>
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span></blockquote></div><br></div></div>