[llvm] [CodeGen] Add EmitCodeGenCallSiteInfo flag (PR #206668)

Nikita Popov via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 10 00:40:07 PDT 2026


nikic wrote:

> Thanks for digging in, and for running the compile-time numbers.
> 
> The callsite info isn't purely internal. `EmitCallSiteInfo` was introduced for debug info, and its consumer is the DWARF emitter, so it's emitted into the artifact under `-g`. For the outliner's use, recording `HasStackArguments` emits nothing; it's read during codegen.

Ah, I see, I was just searching for EmitCallSiteInfo, should have looked for getCallSitesInfo() as well.

It seems like the use in DWARF emission is also partially guarded behind a separate option for emitting debug entry values. But one bit (call site targets for indirect calls) is unconditional, just based on whether call-site info is present.

> That entanglement with debug-info emission is what originally made me reach for a distinct switch rather than overloading `EmitCallSiteInfo`, to keep the side effect of recording `HasStackArguments` scoped. But given your compile-time result, I don't think the worry is strong enough to insist on it. The max-rss bump makes sense: callsite info is heap-allocated per call, so it scales with the call count.
> 
> So if that max-rss increase is acceptable to you, I'm happy to close this PR and rework the `HasStackArguments` PR so that it automatically enables `EmitCallSiteInfo` for AArch64 backends when the machine outliner is enabled. Another option is to maintain a completely separate `HasStackArguments` side table, which would sidestep `EmitCallSiteInfo` entirely. That said, `CallSiteInfo` already fits the purpose well - it's the existing per-call side table - so standing up a parallel structure feels like a waste to me.

I think automatically enabling EmitCallSiteInfo would be the right direction. Frontends shouldn't need to worry about correctly configuring internal implementation details of the LLVM backend.

Probably the ideal way this works is that EmitCallSiteInfo does not exist as an option at all, and is just automatically enabled whenever it is needed for something (call graph section, debug entry values, machine outlining).

The only complication is the issues with the dwarf call site targest mentioned above, where enabling call site info will have a side effect. Ideally that would be controlled separately. (Though I haven't looked deeply into all the surrounding code, it's possible this is already guarded by something...)

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


More information about the llvm-commits mailing list