[PATCH] D50630: [AST] Update/correct the static_asserts for the bit-fields in Type

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

(Just writing up my archaeology and research so no-one else needs to do it...)

We used to intentionally keep the `Type` bitfields 32 bits long. However, these commits (accidentally, as far as I can tell) took us past 32 bits for the type bitfields: https://reviews.llvm.org/rL270834 https://reviews.llvm.org/rL285849 https://reviews.llvm.org/rL301535 https://reviews.llvm.org/rL327768

For a target with 32-bit-aligned pointers, these changes will have made all `Type` objects 4 bytes larger.

For a target with 64-bit-aligned pointers, most `Type` subclasses would not be made any smaller by reducing the bitfields from 64 bits to 32 bits. The following types could be made smaller with some additional effort:

- `DependentAddressSpaceType`, `DependentSizedExtVectorType`, and `DependentVectorType` could each be made 8 bytes smaller by moving their `SourceLocation` member to the start and reordering the bases so `FoldingSetNode` is first. (But we should also remove the `ASTContext&` members if we care about how big these nodes are.)
- `UnaryTransformType` could be made 8 bytes smaller by moving its `UTTKind` member to the start. But it could be made 8 bytes smaller today by just removing that member, because its value is always zero. Or moving that member to the `Type` bitfields.
- `SubstTemplateTypeParmPackType`, `TemplateSpecializationType`, `DependentTemplateSpecializationType`, and `PackExpansionType` could be made 8 bytes smaller by reordering the bases and moving an `unsigned` to the start. Or by moving the member into the `Type` bitfields.
- `ObjCTypeParamType` could be made 8 bytes smaller by reordering bases, but we could get the same benefit by just moving its bitfield member into the `Type` bitfields.
- `PipeType` could similarly be made 8 bytes smaller, but again it'd be easiest to just move its bool member into the type bitfields if we care.

(End archaeology.)

Does anyone still care about the memory uasge of 32-bit clang? (How much effort should we go to to pack our data efficiently for such targets?) Given that there are no `Type` nodes that could be made smaller on a 64-bit system by packing into the tail-padding of `Type` that could not more easily be made smaller in other ways, if we're past the point where 32-bit memory usage is a concern, I think we should just accept that the `Type` bit-fields are 64 bits long now.


Repository:
  rC Clang

https://reviews.llvm.org/D50630