Renato, On Mar 4, 2011, at 10:00 AM, llvmdev-request at cs.uiuc.edu wrote:> 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 > > cheers, > --renatodoes'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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110304/9b2cd2b6/attachment.html>
On 4 March 2011 18:21, Peter Lawrence <peterl95124 at sbcglobal.net> wrote:> seems like two different but related meanings for the word "packed". > > am I confused ?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. ;) 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. cheers, --renato