Re: Update LTO plugin interface

[Jan Hubicka <hubicka at ucw dot cz>]

> >> 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?

Ah, yes.  My first attempt for name was same as yours ;)
GCC knows what COMDATs have to be output even if unused.

> 
> 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.

At GCC side I am trying to keep those grouped. So as soon as you ask for
one symbol from the group, you will get all of them, even if you possibly
decide to resolve others from other group (that indeed should not happen).

Also from QOI point of view, it is better if linker was choosing variant
with IR definitions over variant without if given multiple variants.

Honza
> 
> -cary