r203052 - Construct GlobalValues with the correct linkage instead of using setLinkage.

[Nick Kledzik]

On Mar 6, 2014, at 11:40 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>> weak-def tells the linker the content can be merged/coalesced by name.
>> The ‘l’ symbol prefix tells the linker the not add the symbol name to the final output.
>> This combination really only make sense for visibility=hidden symbols (which they were).
> 
> OK. Lets try to figure out the correct way to represent this at the
> LLVM IR. Some extra questions:
> 
> * Is the merge required to happen or it is just an optimization?
It is an optimization to reduce duplicate copies of objc data structures.
The merge has always happened before, I don’t know if there is anything
in the runtime that relies on that.  But it is a big space savings, so we
would not want to lose this.

> * Is it legal to merge by value?
I’m not sure how well defined “by-value” means when the content is data
with pointers to other objects (which might be merged).  We side stepped
that by giving is a unique name that can be used to merge by-name.

> * Is it legal to drop the symbol if it is not used in a translation unit?
Drop the symbol name or the content too?  Many of these are in 
non-dead-strip sections because their existence has meaning to the objc
runtime.

> * Is the content guaranteed to be the same in every TU?
The objc compiler makes names that imply the content regardless of TU.


> 
> And some observations
> 
> * Using private is currently the only direct way to hide a symbol
> (other than manually applying the 'l' prefix).
> * Using private, linker_private, linker_private_weak or internal is at
> least undesirable. If llvm renames the symbol during IR link, it
> prevents the linker from doing the merge. It might also be incorrect
> if the merge is required to happen or if it is illegal to merge by
> content.
> * The merge by name property at the IR level is only provided by weak,
> linkonce, weak_odr and linkonce_odr, so they do look to be the best
> candidates.
> 
> Since no IR linkage maps directly to what we want, the two options seem to be
> * Keep using an explicit 'l' prefix and one of (linkonce|weak)(_odr|),
> but document why.
> * Add a new linkage that the same as the selected
> (linkonce|weak)(_odr|), but adds the 'l' prefix.
> 
> Given how specific this is, I would probably go with the first option.
Isn’t that what was done before (explicit name)?

This is another reason that the exist big LinkageTypes enumeration does  not
scale.  There is a bunch of independent dimensions (‘l’ prefix is one dimension).
The LinkageTypes is a smattering of common points in N-dimension space.
Each time we find a need for a new point needed, adding it requires finding
all uses of LinkageTypes and updating them.

-Nick