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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
