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

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 13 15:37:37 PDT 2016


mehdi_amini added a comment.

In https://reviews.llvm.org/D23739#541738, @pcc wrote:

> > I don't have an easy access to gold, can you provide the IR and the resolution so that I can reproduce with llvm-lto2?
>
>
> Sure:
>
>  


Thanks.

> > Ultimately we need a consistent story for commons, and document it clearly in the API.

> 

> 

> I think our story for all symbols should be that there can only be a maximum of a single prevailing symbol.


It means that we 1) rely on the client to pick the largest common and 2) we can't adjust the alignment to the largest

So we need to make sure the IRMover handles correctly commons in this case and does not merge them but keep only the prevailing one.

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

> That would be the simplest interface/implementation on the lib/LTO side. It is sufficient for non-ELF, and (with the exception of common symbols) for ELF. There are various workarounds that ELF linkers can use for common symbols, but the implementation of those workarounds ideally shouldn't live in lib/LTO.


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


Repository:
  rL LLVM

https://reviews.llvm.org/D23739





More information about the llvm-commits mailing list