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

Rafael Espíndola rafael.espindola at gmail.com
Thu Mar 6 12:52:08 PST 2014


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

Sure. I am just trying to figure out how it interacts with a partial
LTO, to decide on the IR representation.

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

LLVM would merge it if the objects it points to are merged too. Given
that this is dubious and that any renaming by llvm would prevent
further merging by the linker, it is probably best to go with "merge
only by name" for now.

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

Drop the content. So I assume that content that is currently marked
non-dead-strip must be kept, but other content can be dropped by llvm?

BTW, what is the interaction of N_NO_DEAD_STRIP and S_ATTR_NO_DEAD_STRIP?

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

OK, so it would be one of the _odr linkages. weak_odr if it cannot be
dropped, linkonce_odr if it can.

>> Given how specific this is, I would probably go with the first option.
> Isn’t that what was done before (explicit name)?

Yes. That is what is currently being done. But it was not clear why.
It is also being done for plain private symbols, where it should be
unnecessary.

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

I fully agree.

I actually started doing this to remove the linker_private and
linker_weak_private linkages. The old uses were really just hacks
around llvm not handling private correctly. I removed those already,
so the they are currently dead.

I just wanted to make sure that they were not what was needed for the
objc symbols to avoid the explicit 'l' prefix. Given this discussion I
am pretty sure that linkonce_odr and weak_odr  with an explicit name
is the correct thing to do.

Cheers,
Rafael




More information about the cfe-commits mailing list