================
@@ -2901,34 +2907,44 @@ class CallExpr : public Expr {
//
// * An optional of type FPOptionsOverride.
//
- // Note that we store the offset in bytes from the this pointer to the start
- // of the trailing objects. It would be perfectly possible to compute it
- // based on the dynamic kind of the CallExpr. However 1.) we have plenty of
- // space in the bit-fields of Stmt. 2.) It was benchmarked to be faster to
- // compute this once and then load the offset from the bit-fields of Stmt,
- // instead of re-computing the offset each time the trailing objects are
- // accessed.
+ // CallExpr subclasses are asssumed to be 32 bytes or less, and CallExpr
+ // itself is 24 bytes. To avoid having to recompute or store the offset of
the
+ // trailing objects, we put it at 32 bytes (such that it is suitable for all
+ // subclasses) We use the 8 bytes gap left for instances of CallExpr to store
----------------
hokein wrote:
If I understand correctly, with this patch we’ll now allocate 32 bytes for each
`CallExpr` subclass instance. This slightly increases AST memory usage (24
=>32) for `CXXMemberCallExpr` and `CUDAKernelCallExpr`. That’s probably fine --
from my observation, `CXXMemberCallExpr` accounts for ~2% of all AST nodes.
The 32-byte seems like a strong assumption. It won’t be sufficient if we move
to 64-bit source locations. `CXXOperatorCallExpr` grows from 32 to at least 40
bytes because it stores a SourceRange (coincidentally, I’ve been revisiting
64-bit source locations recently).
https://github.com/llvm/llvm-project/pull/141058
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
