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

[Jim Grosbach]

On Aug 22, 2013, at 2:47 PM, Eric Christopher <echristo at gmail.com> wrote:

>> I think there is no path forward for supporting LTO on the commandline that
>> allows all of the existing users to continue using the command lines they
>> have. We should abandon that hope.
>> 
> 
> Cool deal. I just wanted at least one other person to say "yes, we
> should do that”.

+2 ;)

>> First, -O4 is a *very* bad name. LTO is not about how hard we optimize but
>> about *where* we optimize. I sent out a proposal to eventually make -ON
>> saturate at 3 (possibly with a warning) and there was no real arguments
>> against this a long time ago. I still think that is the correct design
>> there.
> 
> -O4 is an abomination. I agree.

Yes. Let’s kill it sooner rather than later.

>> As Shuxin said, we have two *overlapping* use cases:
>> 
>> 1) I want to do LTO.
>> 
>> 2) I want to get the IR out for some development purpose (I do not care what
>> optimization model is being requested).
>> 
>> The only sensible flag for requesting LTO is '-flto'. Requesting LTO is the
>> only sensible use of that flag.
>> 
>> If you want IR to debug something or see the IR, you don't want to change
>> the compilation or optimization model, you just want to get IR. This is
>> exactly what '-emit-llvm' does and should provide.
>> 
>> If people are surprised by the fact that '-emit-llvm' happens to be a no-op
>> when using '-flto', they will learn something about or LTO.
>> 
>> If people are surprised that passing '-flto' changes the optimization
>> strategy to be better aligned with running the optimizer at link time, they
>> have gotten what they asked for and need to change what they are asking for.
>> 
> 
> I agree with all of these things.

Me too. This is exactly right. Perhaps I’m dreaming on several levels here, but I’d also like to have documentation that effectively communicates all of that and helps prevent those surprises.

-Jim