WenleiHe wrote: > > But disregard the PGO use case mentioned above, I think having the > > extension just for perf critical path is enough of a justification. > > This is going to be significantly worse at optimizing a hot function than the > default inliner is going to be when using profile data. You're also inlining > all of the cold call sites here, significantly increasing icache pressure, > which will decrease performance.
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. 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. https://github.com/llvm/llvm-project/pull/165777 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
