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. And so what I'm discussing is a way for the linker to communicate the relevant part of that information to the compiler plugin. The relevant part is: "this undefined symbol reference in a.o is bound to this symbol definition in b.o." There is nothing else that the compiler needs to know. (Actually, when we move on to applying LTO across shared library boundaries we may also want to say something about the strength of the binding.) I appreciate the cleanliness and simplicity of your description. I'm trying to fill in an ugly edge. The reality is that symbol versions are expressed via assembly language pseudo-ops, both in C/C++ files and in assembly code, and also via version scripts passed to the linker. To the limited extent that the compiler needs to be aware of them, the linker needs to convey that information. If we decree that the information must be expressed directly in the compiler IR, then I think we're looking at a considerably larger degree of ugliness. Ian
