[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

["rafael.espindola at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247

--- Comment #12 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-02-14 19:59:22 UTC ---
A quick summary to see if got this right:

Currently the linker has three options for a symbol in a comdat:

*) pick one not in the IL. The plugin gets a PREEMPTED_REG
*) pick one in the IL and give PREVAILING_DEF to the plugin
*) as above, but PREVAILING_DEF_IRONLY

The first one is undesirable since the more LTO sees, the better.
The second one prevents gcc from dropping tho symbol if it drops the uses.
To give the third option the plugin would have to know the semantics of this
symbol (available anywhere it is used).

The proposal is that PREVAILING_DEF_IRONLY_EXP will let gcc drop all references
if it drops all uses.

Some cases:

*) a visible symbol in IL and there is a reference from it in a ELF file. Gold
must give PREVAILING_DEF to the plugin and it cannot drop it.
*) a visible symbol in IL and there is no references from it in a ELF file.
Gold gives PREVAILING_DEF_IRONLY_EXP to the plugin. What gcc can do then
depends on what the symbol is
  1) if the symbol is one (like vtable) known to be available where it is
needed, gcc can drop it if it drops all uses
  2) if the symbol is a simple weak symbol gcc must keep it
*) a local symbol. gold gives PREVAILING_DEF_IRONLY to the plugin and it can do
anything it wants with it.

On LLVM land I think this translates to

*) If given PREVAILING_DEF, linkonce gets upgrade to weak and linkonce_odr to
weak_odr
*) If given PREVAILING_DEF_IRONLY_EXP, likages stay as they are
*) If given PREVAILING_DEF_IRONLY the symbol gets internalized

I think this should work, thanks.