Interestingly, they want to do the opposite of what Microsoft did with their C++ compiler and linker. To enable "whole program optimizations" Microsoft's compiler writers added the intermediate code analysis, optimizations and code generation to the linker, allowing to, for example, if it is beneficial, inline function invocations for small functions that aren't declared as inline and that come from the different module. So their linker can now do both the classical linking (what Go authors have as the goal now) and the "linker does the code optimization, including intra-module, and generation."
Did Go ever use intra-modules optimizations in their linker? Do Go authors really find there's no need for that, when they want to fix the new object code format to only the "generated code" one?
Go's gc toolchain (as opposed to gccgo) tends to emphasize compile speed over producing optimal executables, so they may be flat-out deciding to leave some potential whole-program optimizations on the table to for link speed--pure speculation, though. (And don't know re: your question.)
Been a while since I looked at ELF but it would sure be nice if it used, say, a well-defined ELF subset to make use of the many ELF tools out there already.
[+] [-] acqq|12 years ago|reply
Did Go ever use intra-modules optimizations in their linker? Do Go authors really find there's no need for that, when they want to fix the new object code format to only the "generated code" one?
[+] [-] twotwotwo|12 years ago|reply
[+] [-] noselasd|12 years ago|reply
gcgo can do inlining across module boundaries.
[+] [-] tomcam|12 years ago|reply
[+] [-] zellyn|12 years ago|reply