similar to: [LLVMdev] Structure Types and ABI sizes

Jochen Wilhelmy <j.wilhelmy at arcor.de> writes: > struct I { > int a; > char b; > }; > > struct J : I { > char c; > }; > > Dave said that this translates to > > %I = type { i32, i8, i16 } > %J = type { %I, i8, i16 } It translates to that in OUR compiler. It's not the only answer. > because the frontend has to communicate the ABI to

>> What I really wonder is why it isn't >> >> %I = type { i32, i8 } >> %J = type { %I, i16, i8 } >> >> because llvm at least knows alignment rules by >> >> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16... >> >> Therefore llvm has no other choice than assigning %I a size of 8 >> since an array may consist of %I

> If %I is not a "POD for the purposes of layout" type, that it's tail > padding MUST be overlapped when inherited from. In this case, we > end up creating two types for %I, %I and %I' and use %I' as the > type when it is inherited from. > But this is the question why two types in this case. if %I = type { i32, i8 }; then %I has 8 bytes if used directly

Jochen Wilhelmy <j.wilhelmy at arcor.de> writes: >> Yes, the padding is required. I believe %J = type { %I, i16, i8 } would >> work just as well as long as %I = type { i32, i8 } as in your example. > Yes but given the ABI requires the last member to be at offset 5, > which may happen > (i.e. no tail padding if I is derived from), then your solution No, this is not

>> %I = type { i32, i8 }; // 5 bytes >> %I' = type { %I, tailpad}; // 8 bytes >> %J = type { %I, i8 } // 6 bytes >> > That would break C code (and whatever else relies on alignment). > why would it break C code? of course a C frontend should generate only tailpadded types. > I don't see a way of specifying two structures, but I like the idea of

> If you're saying that: > > >> %I = type { i32, i8 }; >> > has size 5, yes, you're missing the alignment. > Ah, now I see. But I didn't say that %I = type { i32, i8 }; has 5 bytes (because it has 8) but I thought that it has 5 bytes when being a member of %J, i.e. %J = type { %I, i8 } In this case %I also has 8 bytes right? I was thinking

>> why would it break C code? of course a C frontend should generate only >> tailpadded types. >> > It's not about the size, but the offset. If you had a char field in > the inherited class: > > %I' = type { %I, i8, tailpad}; > > The offset of that i8 has to be 8, not 5. If all structures are > packed, that would be 5, which is correct for

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

On 24 February 2011 15:13, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > but I don't see the point of this since %I already does the job > or do I miss something? If you're saying that: > %I = type { i32, i8 }; has size 5, yes, you're missing the alignment. According to the standard, the alignment of a structure is the alignment of its most-aligned member (and

On 4 March 2011 12:51, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > why would it break C code? of course a C frontend should generate only > tailpadded types. It's not about the size, but the offset. If you had a char field in the inherited class: %I' = type { %I, i8, tailpad}; The offset of that i8 has to be 8, not 5. If all structures are packed, that would be 5,

On 24 February 2011 16:27, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > %I = type { i32, i8 }; // 5 bytes > %I' = type { %I, tailpad}; // 8 bytes > %J = type { %I, i8 } // 6 bytes That would break C code (and whatever else relies on alignment). I don't see a way of specifying two structures, but I like the idea of using a packed structure for inheritance and the

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

Renato Golin <renato.golin at arm.com> writes: >> 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

On 15 February 2011 22:14, David A. Greene <greened at obbligato.org> wrote: > That's why we use { i8, i16 }.  It's not by accident.  We do adhere to > the Itanium ABI. Oh, I see. But the padding is not a problem, it could be [3 x i8] or { i8, i16 }, it doesn't matter, since it's never going to be used. But the [8 x i8] that was the original Base type is, and

Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK:

Am 29.12.2011 19:52, schrieb Reid Kleckner: > I think Chris is saying that the and is necessary because with your i1 > trunc you're ignoring all of the high bits. The and implements that. > If you don't want this behavior, don't generate the trunc in the > first place and just compare the full width to zero. But if a backend sees trunc from i8 to i1 it should know

>> Hi! >> >> before InstCombine (llvm::createInstructionCombiningPass()) I have >> a trunc from i8 to i1 and then a select: >> >> %45 = load i8* @myGlobal, align 1 >> %tobool = trunc i8 %45 to i1 >> %cond = select i1 %tobool, float 1.000000e+00, float -1.000000e+00 >> >> after instCombine I have: >> >> %29 = load i8*

Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is

Hello. I have played with DataLayout and found a solution with is uknown to me. I added S16 and also s0:16:16, but it had not worked. Then I found that in Z80FrameLowering.h I am calling TargetFrameLowering with stack aligment set to 8. So I changed it to 2 bytes. But this also didn't help. Then I changed llc to show TargetDataLayout and found that a option is set to a0:0:64. So I changed

I think Chris is saying that the and is necessary because with your i1 trunc you're ignoring all of the high bits. The and implements that. If you don't want this behavior, don't generate the trunc in the first place and just compare the full width to zero. Reid On Wed, Dec 28, 2011 at 6:45 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de>wrote: > > >> Hi! >