search for: structlayouts

Displaying 20 results from an estimated 54 matches for "structlayouts".

Did you mean: structlayout
2009 Sep 22
3
[LLVMdev] 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 struct test1 { short f0 : 10; char f1 : 5; long f2 : 1;
2009 Sep 23
0
[LLVMdev] StructLayout
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
2012 Mar 22
1
[LLVMdev] StructLayout getSizeInBits()
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
2014 Apr 11
2
[LLVMdev] Advice on field access, adding a Modula-3 front end
On 04/10/2014 09:02 PM, Krzysztof Parzyszek wrote: > On 4/10/2014 8:40 PM, Rodney M. Bates wrote: >> >> I could probably create llvm IR in this style by generating explicit >> address arithmetic, but I suspect that might hurt the optimization >> possibilities, perhaps a lot. It looks like re-raising the level to >> field numbers would not be horribly difficult,
2015 Jun 24
3
[LLVMdev] DataLayout
Hi all, 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
2011 Feb 15
3
[LLVMdev] Structure Types and ABI sizes
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:
2009 Jun 18
1
[LLVMdev] Explicitly Freeing Allocas
I went ahead and implemented the allocation based on the maximum size of all structs seen so far... The problem is, the TargetData object 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.
2011 Feb 15
0
[LLVMdev] Structure Types and ABI sizes
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
2016 Dec 29
4
Structure Padding and GetElementPtr
Thanks, Eli. Next question is how to get the layout of the original C++ class from LLVM IR? Regards, Hu Hong On 29 December 2016 at 01:57, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 12/28/2016 5:41 AM, Hong Hu via llvm-dev wrote: > > Hi all, > > I'm writing a pass to understand the memory access to C++ class members. > For each GetElementPtr instruction,
2009 Jun 18
0
[LLVMdev] Explicitly Freeing Allocas
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: > >>
2011 Feb 15
2
[LLVMdev] Structure Types and ABI sizes
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
2010 Apr 23
2
[LLVMdev] variable sized array
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>
2010 Apr 23
0
[LLVMdev] variable sized array
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
2012 May 24
1
[LLVMdev] About the result of getPointerSizeInBits();
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
2016 Dec 28
0
Structure Padding and GetElementPtr
On 12/28/2016 5:41 AM, Hong Hu via llvm-dev wrote: > Hi all, > > I'm writing a pass to understand the memory access to C++ class > members. For each GetElementPtr instruction, I check the second index > to the class pointer, to figure out which member it is intended to > access. > > However, due to the structure padding, there are some fake members > inserted
2014 Apr 11
3
[LLVMdev] Advice on field access, adding a Modula-3 front end
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
2010 Oct 26
2
[LLVMdev] StructType member offset
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
2009 Jun 18
2
[LLVMdev] Explicitly Freeing Allocas
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
2016 Dec 29
0
Structure Padding and GetElementPtr
Here is an example: I can define two classes: A and Apad: class A { bool b1, b2; double d1; int i1; }; class Apad { bool b1, b2; bool pad1[6]; double d1; int i1; bool pad2[4]; }; A and Apad will have the same layout, from the LLVM IR level: %class.A = type <{ i8, i8, [6 x i8], double, i32, [4 x i8] }> %class.Apad = type { i8, i8, [6 x i8], double, i32, [4
2016 Dec 29
0
Structure Padding and GetElementPtr
Only Clang really knows the original structure layout. You can pass '-Xclang -fdump-record-layouts', though, to see the layout during compilation. The DICompositeType metadata produced when compiling with debug info might contain enough information to describe the original layout. On Wed, Dec 28, 2016 at 6:44 PM, Hong Hu via llvm-dev < llvm-dev at lists.llvm.org> wrote: >