On Jun 5, 2008, at 6:18 PM, Ian Lance Taylor wrote:
How does the linker tell LTO that a symbol may be inlined, but
must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO
engine
is free to inline anything that would improve codegen, with the
exception
that any weak definition that must remain (preserved) cannot be
inlined.
I'll just note that that isn't optimal for ELF when producing an
executable.
Why? Because you have to touch (worst case) every symbol? The cost
of
doing LTO *dramatically* dwarfs the cost of touching symbols once.
:) You're right this could be improved, and we're actively working
on it... but it seems like a strange thing to worry about vs
correctness in all cases.
Whoops, sorry, I meant the other thing. Not inlining any weak
definition that must remain is not optimal. When linking an
executable, it is perfectly OK to inline a weak function, even if the
weak symbol is required to remain in the final output file. In
general if the symbol is known to be bound locally, then it is OK to
inline it. This is separate from the question of whether the symbol
is visible externally.
This isn't an issue in general. Just add a new linkage type that is
"weak but allows inlining" or whatever semantics you want. There is
no great need for your compiler IR to match the linkage model. LLVM
IR currently encompasses the linkage types used in MachO as well as
most in ELF, but it also has types that are neither. The "linkonce"
linkage type in LLVM is most similiar to "non-external weak" linkage
in ELF combined with some random flags that hang out in GCC's cgraph
nodes. If a symbol with that linkage ends up in a .o file, ELF sees
it as 'non-external weak' linkage.
-Chris
