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