[clang] [CodeGen] Mark weak vtables unnamed_addr on duplicable-vtable targets (PR #205930)

[Oliver Hunt via cfe-commits]

ojhunt wrote:

> > > > > I didn't thought the linkage of vtable is related to targets.
> > > > > > On Mach-O, a weak vtable that is unnamed_addr lowers to a .weak_def_can_be_hidden definition
> > > > > 
> > > > > 
> > > > > Is this only possible on Mach-O? I mean, if this is an optimization, why didn't it work on other platforms?
> > > > 
> > > > 
> > > > It may be a matter of other platforms not having got around to it, or platform constraints make it less viable/valuable? It probably benefits platforms where mapped system libraries can be aggressively shared across many processes, but I'm not a linker person if I can help it.
> > > 
> > > 
> > > I still don't understand why this is platform specific... Or what is the bad side of the behavior?
> > 
> > 
> > I think there will be issues where it depends on the stdlib handling RTTI with duplicate type definitions - so probably this is something that each platform needs to decide on
> 
> The OP said:
> 
> "On Mach-O, a weak vtable that is unnamed_addr lowers to a .weak_def_can_be_hidden definition, which the static linker coalesces and then drops from the dynamic export trie. Keeping these vtables out of the exported symbol set cuts the work dyld has to do at load time."
> 
> I think weak symbols can always duplicated on all platforms. And whether or not a symbol can be duplicated shouldn't be related to stdlib as far as I know.

The reason vtables have weak symbols is because they _can't_ be duplicated (according to the standard), the weak symbols are to support unification. 

I guess stdlib is the wrong term - it's the actual runtime implementing RTTI in a way that supports multiple definitions of the same type (e.g. the typename string compare fall back).

There's also an element of: we know the rules for our platform's runtimes and linker, because this technically implies ODR violations, making the decision blindly for other platforms seems questionable.

https://github.com/llvm/llvm-project/pull/205930