<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 8/14/13 12:57 PM, Eli Friedman
wrote:<br>
</div>
<blockquote
cite="mid:CAJdarcG8c=MrUo62OPpk-rQj4m7y5+HXuwcKC4ZMrwDrxQpO1w@mail.gmail.com"
type="cite">
<div dir="ltr">On Tue, Aug 13, 2013 at 5:46 PM, Eric Christopher <span
dir="ltr"><<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
</div>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I'm not sure what you're saying here.
<br>
</div>
</div>
</blockquote>
It is to answer Eric's question. If understand his question right,
he is kind of asking do we need <br>
some flags like -combine in gcc? The answer is "no". <br>
<br>
<blockquote
cite="mid:CAJdarcG8c=MrUo62OPpk-rQj4m7y5+HXuwcKC4ZMrwDrxQpO1w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">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>
<br>
</div>
</blockquote>
<br>
No, the name of the flag dosen't matter. <br>
<br>
Forget my previous mail. The only thing I want to achieve is to <br>
<br>
1) clang -emit-llvm a.c -c , and<br>
2) clang -flto a.c -c<br>
<br>
Without my change, there is no difference between them. <br>
<br>
<br>
</body>
</html>