[llvm] Fix size in bytes of type DIEs when size in bits is not a multiple of 8 (PR #69741)

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 4 10:19:24 PDT 2023


dwblaikie wrote:

> > > Just added some tests!
> > 
> > 
> > Thanks!
> > > Motivation wise: Swift has builtin types which are non-byte-size. For example, the builtin that the standard boolean wraps is 1 bit long.
> > 
> > 
> > Hmm, I'm still not sure about this - if the DWARF is describing it as being 1 byte long, presumably that ABI has to actually allocate a byte for this type? So in what sense is the type only 1 bit long?
> 
> Swift allows packing values in aggregates under certain circumstances. For example the type `Bool?` a.k.a. `Optional<Bool>` stores the discriminator bit of the Optional enum type in bit #1 and the Bool in bit #0 of the same byte. For these applications the bit size is relevant.

Ah - this sounds like a different thing though - like structs with tail padding that derived classes can use, we don't describe the base class with tail padding as being smaller.

I guess maybe a different direction to discuss: I think it's useful for the DWARF output to match the IR metadata. The fact that we encode the size in bits instead of bytes is perhaps a mistake/certainly opens things up to potential variation between the bit size encoding and the byte size encoding.. 

But what does the non-rounded-up/storage bit size being in the IR metadata provide, if the result in the DWARF is rounded up anyway? Are we going to encode both the storage size and the bit size separately? Using what attributes? and/or Is the IR metadata consumed by something else that uses the bit-size?

https://github.com/llvm/llvm-project/pull/69741


More information about the llvm-commits mailing list