[llvm] [MemProf] Disable promotion to function declarations by default (PR #192335)
Arthur Eubanks via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 16 10:43:04 PDT 2026
aeubanks wrote:
> If the new metadata is causing us to have a declaration with external linkage type in one module, with the definition being internal linkage in another module, I believe that is illegal IR. I don't think this optimization is the problem.
I agree that it's wrong to have the wrong declaration, but this happens because ThinLTO moving around function definitions currently has fundamental issues with functions in `ValueAsMetadata`, not because of anything special with `!inline_history`
I can revert the `!inline_history` change while we investigate, but all it does is use function pointers in metadata which is definitely valid IR. the problem is on the ThinLTO side in `dropDeadSymbols` where it keeps around the declaration because there's still a use of the function after dropping the function body, in the form of a `ValueAsMetadata` referencing the function.
e.g.
```
declare void @f() ; body was dropped by `dropDeadSymbols`
define void @g(ptr %p) {
call void %p(), !inline_history !0
}
!0 = !{ptr @f}
```
another alternative I thought of was in ModuleSummaryAnalysis to conservatively add a ref from `@g` to `@f` in the case that we ICP a call to `@f`, but that's weird because it's not actually specifically `@g` where we can introduce a call to `@f`, it's any function in the module.
another hackier approach is to specifically handle `!inline_history` in `dropDeadSymbols`, where we remove all function declarations from `!inline_history` (since declarations in `!inline_history` aren't actually useful).
or perhaps there's some way to prevent functions from being moved between modules if there are metadata references?
https://github.com/llvm/llvm-project/pull/192335
More information about the llvm-commits
mailing list