This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [whopr] plugin interface design



On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:


Chris Lattner <clattner@apple.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]