================
@@ -1829,10 +1829,18 @@ class DeclContext {
// refers to an enclosing template for hte purposes of [temp.friend]p9.
LLVM_PREFERRED_TYPE(bool)
uint64_t FriendConstraintRefersToEnclosingTemplate : 1;
+
+ // Indicates this function is type aware operator new or delete
+ LLVM_PREFERRED_TYPE(bool)
+ uint64_t IsDestroyingOperatorDelete : 1;
+
+ // Indicates this function is type aware operator new or delete
+ LLVM_PREFERRED_TYPE(bool)
+ uint64_t IsTypeAwareOperatorNewOrDelete : 1;
----------------
cor3ntin wrote:
These two bits do not justify their cost in the long run.
There aren't that many places where we would read them, and there aren't that
many operator new.
We should be mindful not to use bits on Decl for things that are frequent
and/or require sema to compute the state which isn't the case here.
I also don't think this commit is a simplification as it just adds more state
to serialize.
Are you concerned about the cost of these functions?
In practice there aren't that many operator new/delete in a program, let alone
with the right number of parameters, so It's not a concern I have at all.
If, however, we find out later that it might be, we can cache the type of
`destroying_delete_t`, etc in ASTContext, or even a set of type identity
allocation functions there (or in DeclarationNameTable, same difference)
So unless @AaronBallman @erichkeane disagree, my preference would be to
- More or less reverse this commit (at least to the extent of not using state
for `isTypeAwareOperatorNewOrDelete` (and certainly not for
`isDestroyingOperatorDelete` that has been the way it is for a while))
- If we later (after this PR is merged) we find out that caching is warranted
for whatever reason, we can consider our options then.
My immediate concern is that I see us needing a couple of bits for contracts
and reflection - and that's just in the next few months.
And sure, no one needs 16K constructor initializers, but we should still be
mindful of long term impact here.
https://github.com/llvm/llvm-project/pull/113510
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
