Update LTO plugin interface

Cary Coutant ccoutant@google.com
Thu Dec 2 00:57:00 GMT 2010

>> I'm also not sure what you mean by "resolved IRONLY except that it is
>> externally visible to the dynamic linker." If we're building a shared
>> library, and the symbol is exported, it's not going to be IRONLY, and
>> I don't see how it would be valid to optimize it out. If we're
> Well, the typical COMDAT symbols (ignoring side cases) needs to be put into
> binary/library only if they are actually used, as all the other DSOs will define
> them too if they are used there.
> So it is valid to optimize out COMDAT after you optimized out all its uses. This
> commonly happens at linktime.

Ahh, OK. I was worried about those side cases where sometimes a pure
reference is emitted. From a linker point of view, that's something
that theoretically could happen, although it may be the case that we
don't actually have to support it. If we had a resolution like
PREVAILING_DEF_IRONLY_BUT_EXPORTED (preferably something shorter than
that), I think that would give the compiler the information it needs.
Is that pretty much what your RESOLVED_IRDYNAMIC was intended to mean?

Another thing that I don't remember offhand whether I got right or not
in gold is that if a COMDAT group is defined in IR and non-IR files,
we want to choose one of the IR files as the instance to keep. I'll
have to check.


More information about the Gcc mailing list