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

[Eric Christopher]

On Thu, Aug 22, 2013 at 2:24 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>
> On 8/22/13 1:52 PM, Nick Lewycky wrote:
>
> Sorry, I totally wasn't following this thread at all. I'm assuming the goal
> is to clean up the flags in preparation of adding more smarts to the "we're
> doing LTO" case?
>
> 80% correct.
>
> Let us use examples to clarify the goal:
>
>  command 1:  clang -flto a.c -c
>  command 2:  clang -emit-llvm a.c -c
>  command 3:  clang -emit-llvm a.c
>  command 4:  clang -O4 a.c -c
>
> The interpretation of these commands WAS:
>    command 1, 2: go through the passes defined in populateModulePasses(),
> and emit a *.bc file.
>    command 3, 4: compile to a.out using LTO
>
>
>  The interpretation of these commands will be:
>    command 1: need to indicate we are preparing for LTO
>    command 2: need to indicate we are *NOT* preparing for LTO

Good with me, though your wording is a bit awkward. I'd have said:

command 1: emit bitcode and if there's any optimization then use the
lto pre-lto pipeline.
command 2: emit bitcode and if there's any optimization then just use
the normal pipeline

Do you agree?

>    command 3: *meaningless*

Error please. :)

>    command 4: unchanged.
>

Equivalent to -O3 -flto?

-eric

>
> On 22 August 2013 13:10, Eric Christopher <echristo at gmail.com> wrote:
>>
>> On Thu, Aug 22, 2013 at 12:53 PM, Eric Christopher <echristo at gmail.com>
>> wrote:
>> > On Thu, Aug 22, 2013 at 12:14 PM, Rafael Espíndola
>> > <rafael.espindola at gmail.com> wrote:
>> >>> 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.
>> >>
>> >> So, the possible changes that people using clang will have to adapt to
>> >> is
>> >>
>> >> 1) Using -flto instead of -emit-llvm when doing an lto build.
>> >> 2) Using -emit-llvm instead of -flto when fetching IL to be passed to
>> >> bugpoint or similar.
>> >>
>> >> I don't think 2 is a big concern, since it is a dev option and we
>> >> change those as needed. Issue 1 is a bit more serious, but the change
>> >> is really simple. The -flto option is also what gcc uses.
>> >>
>> >
>> > The concerns I've seen are that -emit-llvm doesn't work as well as
>> > -flto for the task of grabbing IR for any purpose. Nick is the one who
>> > brought this up within hearing range the other day, maybe he can
>> > explain. FWIW I only think -flto should be used to enable lto mode of
>> > everything on the command line and not for grabbing IR at all. I.e. if
>> > there's no link step then -flto shouldn't do anything.
>
>
> :)
>
> As Eric suggested, I was surprised to discover we have a -emit-llvm flag,
> then more surprised that it didn't bother to pass the right linker flags
> when linking. I think I called it "a broken copy of -flto", arguing that we
> should delete it entirely, in favour of -flto.
>
> As for telling the compiler "I want to build with LTO", we already have -O4
> which is presently equivalent to -O3 -flto. Let's keep that?
>
> Of course!
>
>   "-O4" thing is immaterial here:-).
>
> In the future, -O4 should select the pre-IPO optimizations. (I would also
> like a "-Olto" flag specifically so that I can select the pre-IPO
> optimization stack, even if I'm generating native code directly, for
> debugging and benchmarking and also to keep separate the concerns of
> selecting an optz'n stack and selecting the output format.)
>
>
>
>
> I won't block a patch that changes/removes -flto, but my fingers will still
> be typing it for years to come. I don't want it, but I could live with it.
>
>
>