dwblaikie wrote: > > I'm arguing it doesn't fit it particularly well. We use it for bit fields - > > which are pretty special, for instance, but it seems like this thing isn't > > quite like that - it does have a whole byte size (if you allocated an array > > of them, for instance, I'm guessing they're a byte each, right?) but then > > has some padding bits that can be reused in some circumstances? That's why > > I'm saying it seems like it fits more closely to the struct padding > > representation. > > Swift is really clever at packing at packing aggregate types. For example, > the discriminator bits for enums are always stored in unused bits of the > payload type. For a contrived example, the type Optional<Optional> has a size > of 3 bits.
Sure enough - C++ tail padding does similar things: https://godbolt.org/z/4jsYWK6ev - where t2's member is packed into the tail padding of t1, but still leaves more tail padding for t3. (it's not identical, of course - it's somewhere between C++ tail padding and the ad-hoc stuff we have in LLVM for PointerIntPair, where multiple of those can be nested together and use the remaining bits for another element) https://github.com/llvm/llvm-project/pull/69741 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
