------- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-24 12:15 ------- (In reply to comment #8) > I integrated Dave's patch into LD with some modification (only emit those with > LTO sections) and hacked collect2 to support that. The size gain of LTO, our > main concern, is quite limited for our application. Large amount of functions > called only once cannot be inlined across files because compiler doesn't know > whether they are referred in non-LTO compiled code (mostly hand-code assembly > in our cases). We really need full resolution file, especially > LDPR_PREVAILING_DEF_IRONLY type. I will try next to make LD emit full > resolution file.
Note that for a notable size-gain you likely need to build with -fwhole-program (which means GCC needs to see all references to functions or you need to mark functions which are accessed from assembly code with the externally_visible attribute). > Since GNU LD doesn't have plugin support like GOLD. Won't any changes here be > too invasive/specific for LTO purpose to be accepted by LD? We are fine to > live > with that in our private port. I guess that outputting a full resolution file might be ok with the LD folks as it can be a useful thing for debugging as well. But of course it would be their call, including details of the format. I would also expect that a very simple approach for a collect2-only patch would work most of the times (but when it wouldn't work it could result in wrong-code or final linker failures). Simply decompose lib*.a linker arguments to their respective lib...@offset members for the lto1 invocation (and make lto1 ignore, not barf on non-LTO objects). I will also try to see what incrementally doing the symbol resolution would take. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
