[PATCH] D18298: ThinLTO: do not promote GlobalVariable that have a specific section.

[Mehdi AMINI via llvm-commits]

joker.eph added a comment.

> How frequent/important are the modules where specific sections are used?


Very frequent: NSConstantString (objc) is using a specific section all the time.
(I can't bootstrap clang on OS X without the current diff applied for instance, the ThinLTO link does not succeed)

> Also, I assume the plan is to use the proposed hasSection flag to prevent importing any function containing a reference to a local with that flag set (to avoid introducing a cross-module reference requiring promotion).


Yes.

> If renaming is ok, but not the promotion, then a local function with hasSection can itself be imported, if we keep the imported copy local (in which case functions containing references to it can also be imported).


Probably OK most of the time.

So the only way I could foresee to make it work requires collision detection in names based on the summary. Of course it will require to some changes in the naming scheme (the complication comes from using hashes...).
The hash function is currently   `hash(symbol_name, linkage, module_id)` ; this is the GUID we store in the bitcode *and* we use to index in the global table in the combined index.

We can instead compute another GUID this way: `hash(hash(symbol_name), hash(linkage, module_id)) `.
During the FE phase, we generate in the summary only this part: `hash(symbol_name)` ; this is what we store in the bitcode file. We already have `module_id` and `linkage` propagated somehow.
In the combined index in memory, we store `hash(symbol_name)` in the summary itself (`GlobalValueSummary`), and compute the finale GUID `hash(hash(symbol_name), hash(linkage, module_id))` for the key in the global table.
That way we can always lookup the summary of all the symbol in a module and compare `hash(symbol_name)` to detect the collision.


http://reviews.llvm.org/D18298