Mark Mitchell <[EMAIL PROTECTED]> 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
