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

[Eric Christopher]

On Wed, Aug 14, 2013 at 1:03 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>
> 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>
> 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.
>
> 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.

Right. My comment on this change is, in essence, that people have
depended upon the fact that -flto does what you want -emit-llvm to do
for that compile line for a while. I don't think it's necessarily
right, but that you're going to be breaking current use.

-eric