================
@@ -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;
----------------
steffenlarsen wrote:
Completely coincidentally we don't pay any additional memory here. On 64-bit
systems, the current `Decl` class consists of 28 bytes of non-bit-field members
and 33 bits of bit-field members, which with the 8-byte alignment results in 33
bytes of "content" and 7 bytes of padding. Removing a single bit in the
bit-field would make it 32 bytes of content and no padding, so adding a pointer
and removing a single bit from the bit-field results in the same size.
For 32-bit systems, the story is similar, with 24 bytes of non-bit-field
members and 33 bits of bit-field members. That means 29 bytes of content and 3
bytes of padding, which means 4 bytes of pointer and 32 bits in the bit-field
would result in the same total size.
The [max-rss in the performance
results](https://llvm-compile-time-tracker.com/compare.php?from=7380050ae1a8261400350dd08a952ad3f00db1b3&to=a0af2dabaf4a5a63a8b4d04a5711b42ac0d39420&stat=max-rss)
tells this story as well. 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.
https://github.com/llvm/llvm-project/pull/219138
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
