[LLVMdev] Structure Types and ABI sizes

[Renato Golin]

On 15 February 2011 18:30, David A. Greene <greened at obbligato.org> wrote:
> { int32, int8, { int8 } }
>
> Do I understand you correctly?

Hi David,

I'm actually looking for answers, not requesting features... ;)

That structure would actually solve the problem for this specific
case, but not for the general case. There are far too many exceptions
to be worth make a special case for every one of them.


> 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 }

Not if you follow the Itanium C++ ABI.

In your example it works because { i8, i16 } pads nicely to 4 bytes,
so there is no tail padding. If there is tail padding, the size of the
Base class is different from the size of the Base class inside the
Derived one.

So, in my example "B : public A { char }":

%A = type { i32, i8 }
%B = type { %A, i8 }

A has 8 bytes, as it should, but inside B it has only 5, so B's first
field offset is 5, not 8. This is why we have to do:

%B = { [5 x i8], i8, [3 x i8] }

Adding the 3 bytes at the end is NOT the problem, but revoking the
type (and it's natural alignment) from %A is.


> 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.

My idea was that StructLayout could have more (optional) sources of
information, to do a better job at figuring out sizes and offsets. We
even thought about creating a Pass that will transform from natural
structures, unions and bitfields to the horrible mess it results to
when lowered, but that's avoiding the problem, not solving them.

The IR was designed for type safety and we have far too many hacks in
the type system that all C++ front-ends have to do. Maybe the original
design wasn't followed so closely, or we need a new design document
that clearly states what the goals are, because the way it is, it's
not clear, and it's definitely not good for C++.

-- 
cheers,
--renato