@llvm/issue-subscribers-clang-frontend

Author: Timm Baeder (tbaederr)

@HighCommander4 @cor3ntin

I wonder if we can have a bit in CallExprBitfields to track whether the callee is an ExplicitObjectMemberFunction, so that we can get rid of the call to getCalleeDecl

@zyn0217 If it helps, sure :) But I don't know how easy it is to track that from construction.
getCalleeDecl is also super inefficient. I push a thing to compile-time-tracker to improve getCalleeDecl, we'll see

I wonder if we can find a better way to handle/remove the special case for explicit object member functions

I'm trying a few different things
https://llvm-compile-time-tracker.com/compare.php?from=f4cebe5d73c24ab53917bd58aedc9db892a164ae&to=16077ed74794645452434c9ec761d642789e09ac&stat=instructions%3Au

Nowhere near 10% though

For what it's worth, this is the reason why the code in ExprConstant.cpp generally passes around a const Expr *E instead of a SourceLocation to code that performs some checks and might diagnose -- we used to pass around SourceLocations and it turned out we were spending a significant portion of our time during compile-time evaluation in getExprLoc.

We could generalize the approach there, and create an ExprLoc type that can be used in place of a SourceLocation but is internally represented as a const Expr*. Though it'd obviously be better if we can make getExprLoc itself faster.