On Jun 5, 2008, at 10:38 AM, Ian Lance Taylor wrote:
Sure. But here's the thing: the gcc LTO approach involves having a
regular object with a regular symbol table, and the IR is embedded
in
the object. In other words, we do know the symbol version
information: it's in the symbol table of the object.
Wow, that seems incredibly limiting. This means that your LTO either
has to:
1) treat the object header as part of the IR, or
2) avoid making any changes that would affect exported symbols
Is that right? Why doesn't the "LTO reader" just read the symbol
info
from the ELF header and reflect it into the trees somehow?
For example, earlier Nick suggested that LLVM will not inline a weak
symbol. With ELF it is actually OK to inline a weak symbol when
generating an executable. It is not OK when generating a shared
library, unless -Bsymbolic was used on the linker command line. We
could represent these sorts of details directly in the compiler IR.
But I don't see a big advantage to doing so.
Sure, IMO that information should be reflected in the IR. As you
know, I have a strong bias towards making the IR fully self contained
and self describing. You're right that this may not be absolutely
required though.
Incidentally, your choice 2 above doesn't follow. The LTO compiler is
going to pass a new object file(s) back to the linker. It doesn't
have to have the same set of exported symbols, except in cases where
the linker has directed that some symbol must be available.
If you only have one IPO pass, it doesn't matter. If you have two or
more passes then the first pass needs some way to communicate the
changes it made to the second and later passes. Presumably you don't
want to be hacking on the input object files, and the output object
file doesn't exist yet.
-Chris
