[PATCH] D23739: [LTO] Handles commons in monolithic LTO

[Peter Collingbourne via llvm-commits]

pcc added a comment.

> It means that we 1) rely on the client to pick the largest common


The logic already needs to exist in the linker anyway to handle native object files, so I don't see it as a huge problem.

> and 2) we can't adjust the alignment to the largest


I would ideally want to keep that logic out of lib/LTO (see below).

> I wonder if we don't risk to have some issues though, if a module was generated with a larger alignement, the loads/stores can be annotated with the high alignment (and other optimization relies on that). 

>  Unless the optimizer knows that he can't assume anything on the alignment of commons...


If we avoid emitting common symbols into the module, we can avoid this problem. I suspect optimizations involving alignment of common symbols to be rare, so maybe it's not worth the additional complexity to support them.

> Can you clarify what makes it different for non-ELF linker to handle common? (Or what makes ELF linker to need workaround).


I was operating on the assumption that non-ELF linkers only take max size, which would make it straightforward to pick a single prevailing symbol, but from IRC it sounds like linkers for most object formats do in fact want something similar to max size + max alignment.

The workaround I speak of is whatever is needed to create a symbol with the correct size and alignment. That can be done by synthesizing a common symbol that would be internal to the linker (i.e. not creating it in the module) and reporting all common symbols to lib/LTO as non-prevailing, or by creating a common symbol in the module and hence the native object file (which is what the code is currently doing).

If clients can synthesize the symbol, we can avoid having to deal with this issue in lib/LTO. Creating the symbol in the native object file also seems like it may be more complicated on the linker side because it would need to be merged with any other native symbols. So I think the API should be targeted to clients that can synthesize a common symbol, which means having a single prevailing symbol and ignoring all others.

On the other hand, there are clients (i.e. gold) that need the common symbol in the native object file, so maybe this can be a feature of lib/LTO until we have a chance to do something more principled in a way that would be compatible with gold (e.g. the gold plugin could use MC to create its own native object file with the common symbol resolutions).


Repository:
  rL LLVM

https://reviews.llvm.org/D23739