[clang] [llvm] [clang/LLVM] Add flatten_deep attribute for depth-limited inlining (1/2) (PR #165777)
Aiden Grossman via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 4 13:57:05 PST 2025
boomanaiden154 wrote:
> You are making assumption of how users use them. There are cases where adding alwaysinline would be worse than default inliner decision, if it's not used carefully. But alwaysinline is still a valuable tool provided by compiler to certain users.
I am not making an assumption about how users would use this. Not being able to take into account the hotness of a callsite when making inlining decisions will reduce performance compared to when you can take it into account.
`alwaysinline` is way more specific than this, which alleviates the problem.
> Same goes for this extension, the effectiveness depends on how and where users apply it. Not using it correctly can cause worse performance is not a reason to not give that tool to users, otherwise alwaysinline would not exist either. One example, using this for memory allocator fast path when PGO isn't available (e.g. pre-builds) is one of those cases can benefit from it.
> That said, I agree that using this to handle PGO stale profile may not be sustainable -- i won't do that.
These two statements seem to be in conflict to me. It's also not clear to me why adding `alwaysinline` to a couple functions within the allocator fast path wouldn't be sufficient to solve the problem.
https://github.com/llvm/llvm-project/pull/165777
More information about the llvm-commits
mailing list