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

[Eli Friedman]

On Tue, Aug 13, 2013 at 5:46 PM, Eric Christopher <echristo at gmail.com>wrote:

> On Tue, Aug 13, 2013 at 5:29 PM, Shuxin Yang <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>
> >> 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.  We have to have some flag to
enable/disable LTO... are you saying it shouldn't be -flto?

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