ebevhan added a comment.

In D85191#2193645 <https://reviews.llvm.org/D85191#2193645>, @rsmith wrote:

>> This is not ideal, since it makes the calculations char size dependent, and 
>> breaks for sizes that are not a multiple of the char size.
> How can we have a non-bitfield member whose size is not a multiple of the 
> size of a char?

Downstream, we have fixed-point types that are 24 bits large, but where the 
char size is 16. The type then takes up 2 chars, where 8 of the bits are 
padding. The only way in Clang to express that the width of the bit 
representation of a type should be smaller than the number of chars it takes up 
in memory -- and consequently, produce an `i24` in IR -- is to return a 
non-charsize multiple from getTypeInfo.

We did it this way because it was possible. If the intent is for getTypeInfo to 
always return sizes that are multiples of the char size, then the design should 
be inverted and getTypeInfo should simply be calling getTypeInfoInChars and 
multiply that result by the char size. But that isn't how it works.

  rG LLVM Github Monorepo



cfe-commits mailing list

Reply via email to