[clang] [llvm] [Clang][AST][NFCI] Make Decl reference attributes directly (PR #219138)

[Steffen Larsen via llvm-commits]

================
@@ -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