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

[Shuxin Yang]

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
    command 3: *meaningless*
    command 4: unchanged.

>
> On 22 August 2013 13:10, Eric Christopher <echristo at gmail.com 
> <mailto:echristo at gmail.com>> wrote:
>
>     On Thu, Aug 22, 2013 at 12:53 PM, Eric Christopher
>     <echristo at gmail.com <mailto:echristo at gmail.com>> wrote:
>     > On Thu, Aug 22, 2013 at 12:14 PM, Rafael Espíndola
>     > <rafael.espindola at gmail.com <mailto: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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130822/65366356/attachment.html>