[llvm] [MemProf] Handle empty stack context during ThinLTO cloning (PR #81008)

Teresa Johnson via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 8 06:06:00 PST 2024


teresajohnson wrote:

> > Presumably this happened as a result of inlining, but
> > in theory the metadata should have been replaced with an attribute in
> > that case.
> 
> BTW, I'm investigating one problems now that IR metadata doesn't match function summary. I found one function foo(template function) is linkonce linkage after thin_compile and it has many copies. Copy1 inlines it's callee and copy2 doesn't. So copy1 has one callsite metadata but copy2 doesn't. Copy1's linkage is weak_odr and copy2's linkage is AvailableExternallyLinkage in function summary after thin_link. The problem happens in thin_backend, compiler choose copy2's definition and copy1's summary. And finally trigger an assertion.

Hmm, the fact that copy1 has weak_odr linkage and copy2 is available_externally indicates that the linker chose copy1 as the prevailing copy. I suppose we must have decided to import copy2 instead of copy1 for some reason (it can happen, e.g. copy1 might be over the instruction threshold due to the additional inlining, but copy2 wasn't). The code in the backend for cloning does try to locate the summary in that module, but it is the module we are compiling which isn't the module of where we imported from (we no longer have that info). We fall back to selecting the first copy, which is likely the prevailing copy: https://github.com/llvm/llvm-project/blob/fe8a62c46365f5ef0c15df2265bbf0026d0a4047/llvm/lib/Transforms/IPO/MemProfContextDisambiguation.cpp#L3376-L3381

I'm surprised I haven't hit this issue yet...need to think about the best way to solve this. A couple of possibilities off the top of my head:
1) Restrict importing to import only the prevailing def (we have this info in the importer, it is already used for global var importing).
2) Carry some extra info on imported defs (e.g. metadata) indicating the original module.

1 is pretty straightforward. We may lose some importing but it is only in some corner cases like this one. However, then in the cloning code I link to above we rely on the first linked copy being the prevailing one (likely but not 100% guaranteed). So 2 may be better overall.

https://github.com/llvm/llvm-project/pull/81008


More information about the llvm-commits mailing list