================
@@ -355,6 +351,13 @@ class alignas(8) Decl {
LLVM_PREFERRED_TYPE(Linkage)
mutable unsigned CacheValidAndLinkage : 3;
+ /// The attributes attached to this declaration, or null if it has none.
+ ///
+ /// This pointer is the sole record of whether the declaration has
+ /// attributes, so it must be cleared whenever the vector becomes empty.
+ /// Owned by the ASTContext that allocated it.
+ AttrVec *Attrs = nullptr;
----------------
AaronBallman wrote:
> Completely coincidentally we don't pay any additional memory here.
Welllllllll, yes and no. The expectation is that we pay *very close* attention
to memory here because this is the base class for one of the most common AST
nodes in a TU. That said, folks will sometimes make changes here without paying
attention to memory. Then later, we find that to have been a mistake and need
to fix it.
> All that said, it is a valid concern if we expect the bit-field to grow in
> the future given we currently have free space ready for it, while this change
> would require the bit-fields to take up an entirely new 8 bytes.
We don't grow this bit-field often but I would not be surprised if we needed to
in the future.
I think the tradeoff here is really about whether we expect more declarations
with attributes than without. When the compiler got started, attributes were
common enough but not ubiquitous. You'd see them on functions most often, with
plenty on typedefs and type declarations and then a smattering in other
declarations. I think those are still the most common places to see attributes,
but now we're seeing more attribute use in general and more on things like
parameters and data members. So perhaps we've hit a tipping point where this
really does make sense on `Decl`.
That said, I do worry this is purely wasted space on things like
`AccessSpecDecl`, `FriendDecl`, `DecompositionDecl`, `StaticAssertDecl`, the
various kinds of `BaseUsingDecl`, etc. We shouldn't measure just the size of
`Decl` as this will change the size of all the derived classes too. Are there
more bits we need to shuffle around elsewhere to avoid overhead from those?
https://github.com/llvm/llvm-project/pull/219138
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
