[cfe-dev] Alignment of bitfield structs

[Renato Golin]

On 21 April 2015 at 17:06, Reid Kleckner <rnk at google.com> wrote:
> Is "ABI alignment" just the alignment of an i64 as specified in DataLayout,
> or is it something else? Maybe we are computing that alignment incorrectly,
> and the alignment of an i40 should be 4.

Alignment of bitfields in ARM depends on the alignment of the declared
type. In this case, int, or 4 bytes. What happened in this example is
that there are more bits than 32, but the ABI states that you must use
containers aligned to the declared type, so even if you use more than
32 bits, you still need to align to 4 bytes. This essentially means
that you just keep using 4-byte integer containers until all bits fit
inside.

Since i40 doesn't exist in any target, LLVM does the obvious thing and
promotes it to i64, but again, on ARM, long long (which is what i64
means) aligns to 8 bytes, then you have the conflict. I cannot imagine
a pass in LLVM that would see an i40 and split it into i32+i8 and
convert to { i32, i32 } just because it used to be a bitfield. Too
many things can go wrong, including alignment.


> Alternatively, we could have Clang slap 'align 4' on the global and call it
> fixed.

Would LLVM understand that correctly? Would the ARM backend interpret
that correctly and "realise" it's supposed to extend only the extra i8
to an i32? Would that work on other backends? Or would it be better to
let Clang, which knows about the ARM ABI, to emit { i32, i32 }?

I think those would be the questions that I'd be trying to answer
before proposing any changes to how we represent bitfields in the IR.

cheers,
--renato