Re: Planned LTO driver work

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
>> 1. Add a --lto option to collect2.  When collect2 sees this option,
>> treat all .o files as if they were .rpo files and recompile them.  We
>> will do this after all C++ template instantiation has been done, since
>> we want to optimize the .o files after the program can actually link.
>>
>> 2. Modify the driver so that --lto passes -flto to the C front-end and
>> --lto to collect2.
> 
> Sounds workable in general.  I note that in your example of
>   gcc --lto foo.c bar.o
> this presumably means that bar.o will be recompiled using the compiler
> options specified on that command line, rather than, say, the compiler
> options specified when bar.o was first compiled.  This is probably the
> correct way to handle -march= options.

I think so.  Of course, outright conflicting options (e.g., different
ABIs between the original and subsequent compilation) should be detected
and an error issued.

There has to be one set of options for LTO, so I don't see much benefit
in recording the original options and trying to reuse them.  We can't
generate code for two different CPUs, or optimize both for size and for
space, for example.  (At least not without a lot more stuff that we
don't presently have.)

> I assume that in the long run, the gcc driver with --lto will invoke
> the LTO frontend rather than collect2.  And that the LTO frontend will
> then open all the .o files which it is passed.

Either that, or, at least, collect2 will invoke LTO once with all of the
.o files.  I'm not sure if it matters whether it's the driver or
collect2 that does the invocation.  What do you think?

In any case, for now, I'm just trying to move forward, and the collect2
route looks a bit easier.  If you're concerned about that, then I'll
take note to revisit and discuss before anything goes to mainline.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713