search for: structlayout

How are bitfields handled in StructLayout? In LLVM 2.5 the struct is unambiguously size by: StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data In LLVM 2.6 it's getTypeAllocSize, which does the same thing. Unfortunately, this is not correct for bitfields. For example, LLVM reports this struct: typedef struc...

I have a question. If the size of long is 8 on your x64 platform. Because the size of long is so different on different platform, sad it is. 2009/9/23, David Greene <dag at cray.com>: > How are bitfields handled in StructLayout? In LLVM 2.5 the > struct is unambiguously size by: > > StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data > > In LLVM 2.6 it's getTypeAllocSize, which does the same thing. > > Unfortunately, this is not correct for bitfields. For example, > LLV...

LLVMers, I have a const StructType *StTy where I call TargetData->getStructLayout(const_cast<StructType*>(StTy))->getSizeInBits() but it continues to return 64 regardless of the actual size of the struct? I want the size of the structure in bits, including alignment padding for offset calculations, is this not the right function call? Thanks. -------------- next part -...

...here to find a field sequence number. > >> I presume llvm does its own memory layout for structs? > > It uses the data layout that is provided when you create the TargetMachine for a given target. In other words, it can be different for each supported target. > So it looks like StructLayout::Structlayout does _not_ reorder non-packed fields. Can I rely on this? I thought I remembered reading something to the contrary somewhere in the documentation. > >> It is worse with global variables and constants. Here, in the M3 IR, >> for each compilation unit, these have been...

...We have multiple DataLayout object in flight during a compilation: at least the one owned by the Module and the one owned by the TargetMachine. There are two issues: 1) What if they differ? I guess we could assert at the beginning of CodeGen. 2) The DataLayout has internal mutable state (a cache of StructLayout). The latter is my current concern: the cache in DataLayout is based on Type pointer which means that is has to be Context specific. This is fine with the DataLayout attached to the Module but not with the TargetMachine. The cache could live in the Context, but it is also DataLayout specific so i...

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: %struct.I = type { i32, i8 } struct I { int a; char b; }; // CHE...

...t from ExecutionEngine gives me a size of 12 for a struct containing a pointer and an i64 (on a 32-bit machine). However, the generated code seems to assume an alignment of 8, and tries to read the i64 value at offset 8, which obviously reads an invalid value. Does the getSizeInBytes() method from StructLayout not take the alignment into account? - Max Olivier Meurant wrote: > > In the TargetData class (available from you ExecutionEngine), you have > some > informations available (such as StructLayout...). > > > On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca&gt...

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

.... > > Is there any way to map this "5th" access to the original "3rd" one? For > example, some APIs to tell whether one member is a real member, or a padded > one? > > > I would suggest converting the index of the struct GEP into an offset in > bytes; see StructLayout::getElementOffset. You can then compare that to > the layout of the original C++ class. > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > > ------...

In the TargetData class (available from you ExecutionEngine), you have some informations available (such as StructLayout...). On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote: > > That sounds rather cumbersome, is there no simpler way to get the actual > size > of a struct? > > > John Criswell wrote: > > > > Nyx wrote: > >> Hello, > >> &gt...

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

Hi all, just a quick question, in llvm::TargetData, uint64_t MemberOffsets[1]; // variable sized array! MemberOffsets has two elements, why it's variable sized ? yuanfang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100423/6e0d57a5/attachment.html>

Hi Yuanfang, > just a quick question, in llvm::TargetData, > > uint64_t MemberOffsets[1]; // variable sized array! > > MemberOffsets has two elements, why it's variable sized ? when a StructLayout object is allocated (in TargetData::getStructLayout), extra memory is allocated, more than that given by the size of the type. The extra memory is interpreted as being part of the MemberOffsets array, and is used for storing additional member offsets beyond the first one. This kind of trick genera...

Hi guys, Does getPointerSizeInBits need to return sizeof(void*) in Platform? I found that getPointerSizeInBits return 8 in x86-32 on win7-64, MSVC 2010. And if I have a struct { i32, i32* }; the structLayout->getElementOffset(1) return 8, but I think 4 is right. In generated ASM, the offset of second element is 4. Thanks. -- Ye Wu CELL: +86 159 9957 0103 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2012052...

...> member. > > Is there any way to map this "5th" access to the original "3rd" one? > For example, some APIs to tell whether one member is a real member, or > a padded one? > I would suggest converting the index of the struct GEP into an offset in bytes; see StructLayout::getElementOffset. You can then compare that to the layout of the original C++ class. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTM...

I am doing some preliminary investigation into splicing the Modula-3 compiler front end onto llvm. I have a number of questions and will no doubt have more, but will start by asking for advice on this one. The M3 front end has lowered things farther than the llvm IR expects. Whereas llvm accesses fields/data members of records/structs by field number, M3 has already laid out the format of

Hi, how can i correctly calculate the size of a member of a struct (including alignment etc)? This doesn't work : const StructType *STy = cast<StructType>(Ty); for (StructType::element_iterator I = STy->element_begin(), E = STy->element_end(); I != E; ++I) { usigned size =I->get()->getScalarSizeInBits(); //often

That sounds rather cumbersome, is there no simpler way to get the actual size of a struct? John Criswell wrote: > > Nyx wrote: >> Hello, >> >> I would just like to ask if it's possible to explicitly free allocas. >> This >> is because I need to call functions that take structs of different sizes >> as >> input, (possibly inside of loops) and I

...way to map this "5th" access to the original "3rd" one? For >> example, some APIs to tell whether one member is a real member, or a padded >> one? >> >> >> I would suggest converting the index of the struct GEP into an offset in >> bytes; see StructLayout::getElementOffset. You can then compare that to >> the layout of the original C++ class. >> >> -Eli >> >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborat...

...way to map this "5th" access to the original "3rd" one? For >> example, some APIs to tell whether one member is a real member, or a padded >> one? >> >> >> I would suggest converting the index of the struct GEP into an offset in >> bytes; see StructLayout::getElementOffset. You can then compare that to >> the layout of the original C++ class. >> >> -Eli >> >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborat...