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

[Shuxin Yang]

Hi, Rafael:

    Thank you for your input. see following interleaving response.

On 8/21/13 8:30 PM, Rafael Espíndola wrote:
> On 13 August 2013 19:20, 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.
> First of all sorry for being so late on this thread.
>
> I am not sure what you mean by "pre-ipo passes",
Sorry for not being clear. I refer the passes corresponding to "clang 
-flto a.c -c" "pre-ipo passes"/pre-lto passes.

Currently, the "pre-lto passes" ordering is embodied by 
"PassManagerBuilder::populateModulePassManager()".



> but yes. We need two
> different options. One is a developer options for "give me the IL for
> this TU as it was before codegen". The other one is "write IL to disk
> so that we can do LTO". For example, one likely difference will be
> being less aggressive during inlining in each TU.

Yes.

Another example is vectorization, which is better done after 
inter-procedural optimization(IPO), i.e
it is better done in "clang *.o -flto" than "clang -c -flto a.c". The 
reason is after IPO, the vectorizer
(and other loop optimizer) have more detailed information about loop, 
say, the trip-count become
constant after IPO.


I have some local change about changing pass ordering, in general it 
improve performance.
But it has some regression as well. I don't have time to get rid all of 
them at this moment.
But I'd like to commit this tiny change first because I think it is 
useful for other people as well.

>
> I agree that we can use -emit-llvm for the dev option and -flto for
> the user option.
>
>>   However, it changes the semantic of this command:
>>
>>     clang -emit-llvm a.c # NOTE: no -c.
>>
>>   I'm wondering if this command make sense or not.
> Probably not. I would suggest just producing an error if -emit-llvm is
> given with anything but -S or -c.
>
>
Yes