Chris Lattner <[EMAIL PROTECTED]> writes: > 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?
That would be fine. It would require teaching the compiler about symbol versioning and resolution rules which the linker already knows. I sort of think that is unnecessary. But I'm not opposed to it. Of course there is the issue that some of this information also comes from linker command line options. That also has to be fed into the IR. 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. I'm proposing, instead, that the linker inform the compiler plugin about this information based on link-time information. That is a way of representing it in the IR, of course. But it seems to me to be somewhat more pragmatic. 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. Ian
