[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