[PATCH] D31352: Linker: Mark non-prevailing dllexport symbols as exported with a linker flag.

[Rafael Espíndola via llvm-commits]

> We're talking about changing the semantics of dllexport on declarations,
> though, and the inliner can't inline a declaration.

The issue is the inliner inlining the last use of a dllexport
linkonce_odr and then deleting that definition. It has to actually
convert it to a declaration (or add it to the linker command).

> In practice, we give all dllexport definitions a non-discardable linkage, so
> the inliner doesn't normally have to do anything.

OK, if we add a check to the verifier that all dllexport GVs are non
discardable I would be OK with this change. It would still be nicer to
have the notion that a declaration can have semantic meaning to handle
the visibility case, but we can fix that another time.

> What do you think should happen if the user feeds LLVM a discardable
> dllexport inline function? It doesn't seem reasonable for LLVM to inline the
> function, delete the body, and leave behind a dllexport declaration that
> will generate an -export .drective referencing an undefined symbol. Maybe we
> should consider rejecting exported discardable things in the verifier?

Rejecting them works for me.

Cheers,
Rafael