LLVMdev Digest, Vol 81, Issue 5


That’s what the packed is for.

%Base = type { i32, i8 }; // size = 8

%POSDerived = type { %Base, i8 }; // i8 offset = 8, size 12

%Basep = packed type { i32, i8 }; // size = 5

%nonPOSDerived = type { %Basep, i8 }; // i8 offset = 5, size 8



does’t the %nonPOSDerived type have to be packed for its non-Natural size 5 member to
end up with only 5 bytes within its encompassing struct…

sure the i8 can be on any boundary, but %Basep can only be accessed within %nonPOSDerived
as a non-Natural sized object if %nonPOSDerived is itself declared as packed, otherwise if
%nonPOSDerived is not packed then it can contain only Natural sized fields.

so it seems that both structs need to be declared packed, one so the size can be known as less than
a whole Natural size, and the other so that its fields can be fit together tightly without padding.

seems like two different but related meanings for the word “packed”.

am I confused ?

Peter Lawrence.

Hi Peter,

You're absolutely right.

Using the packed attribute was an idea presented by John in the
beginning of the thread and I found elegant and simple, and since then
I'm trying to stress the boundaries of it to make sure if I ever go in
that direction, I'll not end up with yet another load of kludge as I
have now.

Some people have shown counter-examples that some kludge will be
required (including having non-packed structures with packed
structures inside, or a special type of packed that only packs the
last member). I'm losing confidence in this idea already. :wink:

Jochen proposed a keyword "inherit" to stress the packing of the
tail-pad only, that would solve both problems, but introducing new
keywords to LLVM IR is always a dangerous enterprise. While this is
obviously a benefit for C++ (and I'm biased to request that keyword),
it might be used by other languages with slightly different semantics
and it'll be difficult to not add kludge to whatever part that does
the magic.

The Itanium C+ ABI is full of magic and we're bound to produce kludge
somewhere if we are to support C++ along with other languages. Today
we all do that kludge in the front-end, the idea was to simplify it,
but at what cost? It depends on what the IR is for in the long run.