<div dir="ltr">On Tue, Aug 13, 2013 at 5:46 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Tue, Aug 13, 2013 at 5:29 PM, Shuxin Yang <<a href="mailto:shuxin.llvm@gmail.com">shuxin.llvm@gmail.com</a>> wrote:<br>

> Hi, Eric:<br>
><br>
>  Thank you for the code review.<br>
><br>
><br>
> On 8/13/13 5:15 PM, Eric Christopher wrote:<br>
>><br>
>> On Tue, Aug 13, 2013 at 4:20 PM, Shuxin Yang <<a href="mailto:shuxin.llvm@gmail.com">shuxin.llvm@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>>      Driver::IsUsingLTO()  returns true when "-emit-llvm" is seen, which<br>
>>> is<br>
>>> quite awkward if we need to differentiate following two commands, where<br>
>>> 1) is just go through regular passes and stop at llc, while 2) needs to<br>
>>> go<br>
>>> through<br>
>>> pre-ipo passes.<br>
>>><br>
>>>     1) clang -emit-llvm a.c -c , and<br>
>>>     2) clang -flto a.c -c<br>
>>><br>
>>>   With this tiny patch is to differentiate these two situations.<br>
>><br>
>> This is a laudable goal, though i'm not sure what we gain here. I.e.<br>
>> Sadly, using -flto to grab bitcode out has been "the way" to do it for<br>
>> long enough that it's fairly baked in.<br>
><br>
><br>
> There are couple of reasons for differentiating them.<br>
><br>
> For instance, vectorization should not be conducted in 2) because it is too<br>
> early to kick in --<br>
> after aggressive inter-procedural optimization, some symbolic trip-count<br>
> will become constant, and some functions are inlined, enabling more<br>
> opportunities etc...<br>
><br>
> In short,  2) tries to eliminate as much as redundancy without increase code<br>
> size,<br>
> and basically, most loop transformations, no matter it's on a single loop,<br>
> or a loop nest,<br>
> must be disabled in 2).<br>
><br>
> Thank you again for the code review.<br>
><br>
<br>
</div></div>I'm not sure this is a good motivation really. I'd almost rather<br>
redefine the interface for "please compile all of these files (*) as<br>
one single monolithic entity" and have the driver handle how to invoke<br>
the various optimizer levels and at what point we actually merge the<br>
modules (and then what passes we run after that).<br>
<div class=""><div class="h5"></div></div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not sure what you're saying here.  We have to have some flag to enable/disable LTO... are you saying it shouldn't be -flto?<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Eli</div></div>