[LLVMdev] Structure Types and ABI sizes

David A. Greene greened at obbligato.org
Tue Feb 15 10:30:08 PST 2011


Renato Golin <renato.golin at arm.com> writes:

> Example:
>
> // CHECK: %struct.I = type { i32, i8 }
> struct I {
>   int a;
>   char b;
> };
>
> // CHECK: %struct.J = type { [8 x i8], i8, [3 x i8] }
> struct J : I {
>   char c;
> };
>
> What happens here is that "c" is placed in the base's tail padding and
> there are three bytes padding because of the alignment. The main
> problem with this is that, by changing the member (that should be a
> structure) to an array, the alignment is lost. As LLVM types don't

I don't completely understand what you're saying here.  Are you saying
you want to have a J member of I repesented in LLVM, so that struct J
becomes:

{ int32, int8, { int8 } }

Do I understand you correctly?

> So, I'm not proposing to have alignment in types nor to make LLVM
> struct types conform to a specific ABI of a specific language, I'm
> just saying that there should be a cleaner way... Very much like the
> union type and bitfields, structure size and alignment problems can be
> very hairy. Simplifying the IR and leaving all decisions to the
> back-end can be a daunting task, but leaving the front-end to decide
> on sizes and alignment is maybe not the best alternative.

I think it's really the only alternative.  LLVM is a low-level IR.
Expressing things like inheritance and layout rules for such types is
beyond the scope of the language.  There are too many variations among
high-level languages and target ABIs.  For things like that the frontend
needs to insert its own padding bytes.

There are ways to do that without losing too much information.  For
example, we render the above without using arrays at all:

%I = type { i32, i8, i16 }
%J = type { %I, i8, i16 }

There are some places where LLVM can do a better job, I think.
StructLayout should "just work" in more cases.  But the kind of
generality you're talking about just isn't going to work very well in a
low-level IR.  Nor should it.  It's not what the IR is designed to do.

                            -Dave



More information about the llvm-dev mailing list