Re: Planned LTO driver work

[Ian Lance Taylor <iant at google dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

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

I think in the long run the driver should invoke the LTO frontend
directly.  The LTO frontend will then presumably emit a single .s
file.  Then the driver should invoke the assembler as usual, and then
the linker.

That will save a process--if collect2 does the invocation, we have to
run the driver twice.

Bad way:

gcc
  collect2
    gcc     <-- there is the extra process
      lto1
      as
    ld

Good way:

gcc
  lto1
  as
  collect2
    ld

(or else we have to teach collect2 how to invoke as directly, which
just sounds painful).

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

No worries on my part.

Ian