Previously the prevailing information was not honored, and commons
symbols could override a strong definition. This patch fixes it and
propose the following semantic for commons: the client should mark
as prevailing the commons that it expects the LTO implementation to
merge (i.e. take the maximum size and alignment).
It implies that commons are allowed to have multiple prevailing
definitions.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
The problem with this solution is that it requires the client to report all instances of the common symbol as prevailing. gold reports a single instance of the symbol as prevailing, and it won't necessarily be the first one. So the gold plugin can't know whether to report any given non-prevailing common symbol as prevailing since it doesn't know whether the eventual prevailing instance will be common or not. That's what the CommonResolution::Prevailing bit was tracking in the original gold plugin code. I think we'll need something similar here.
Change the API contract: if a least one instance of a common symbol is marked as prevailing, make sure it has the max(size) and max(alignment) over all the common instance for this symbol.
test/tools/llvm-lto2/X86/common.ll | ||
---|---|---|
57 ↗ | (On Diff #71425) | Isn't is already what LARGE-PREVAILED and SMALL-PREVAILED are? |
LGTM
Isn't is already what LARGE-PREVAILED and SMALL-PREVAILED are?
Yes, sorry, I missed those.
One other thing: the test you are updating should live in test/LTO/Resolution/X86 because it is testing the API rather than the command line tool.