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

Nick Lewycky nlewycky at google.com
Thu Aug 22 13:52:26 PDT 2013


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?

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? 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.

Nick


> >
> > This would be a change in behavior though.
> >
>
> Since I've obviously confused Rafael a bit as well let me attempt to
> be a bit more clear here:
>
> a) I'm not, ultimately, objecting to the patch pending some horrible
> statement from Nick.
> b) I agree on principle with -flto doing different things from
> -emit-llvm, especially as a flag to modify and change the pass
> manager.
> c) I think if we make the change on -flto != -emit-llvm then
> -emit-llvm should error if it isn't passed as part of -c or -S.
> d) We could probably use some documentation. :)
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130822/df02e0cc/attachment.html>


More information about the llvm-commits mailing list