[PATCH][Clang Driver] Driver::IsUsingLTO no longer return true when seeing -emit-llvm

Shuxin Yang shuxin.llvm at gmail.com
Wed Aug 14 13:03:29 PDT 2013


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

> We have to have some flag to enable/disable LTO... are you saying it 
> shouldn't be -flto?
>
>

No, the name of the flag dosen't matter.

Forget my previous mail.  The only thing I want to achieve is to

1) clang -emit-llvm a.c -c , and
2) clang -flto a.c -c

Without my change, there is no difference between them.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130814/942d3c47/attachment.html>


More information about the llvm-commits mailing list