[whopr] plugin interface design

[Chris Lattner]

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