On Mar 6, 2014, at 11:40 AM, Rafael Espíndola <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
