On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
I don't know how closely your plans follow this model. If you think
this approach is reasonable, you really do need to reflect things
like
symbol versions in your IR somehow. This compiler must know about
versions, and when it does, it is easy to avoid optimizations that
are
invalid for them.
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?
-Chris
