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