similar to: 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

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,

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

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: >

Yes. LLVM types != C++ types. There is no mapping except that produced if you add debug info. On Wed, Dec 28, 2016 at 6:51 PM, Hong Hu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 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;

Yes, Reid. I have used these methods to figure out the layout. Now my question is to build a map between the original layout and the new layout. I show one example below. When LLVM IR access the 4th (starting from 0th) member (i32) of the class A, the map will tell that in fact it is accessing the originally 3rd member (i1). Any suggestion? Regards, Hu Hong On 29 December 2016 at 10:50, Reid

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

Dear all, I'm currently working on the automated program analysis tool AProVE (http://aprove.informatik.rwth-aachen.de/) and would like to use LLVM for analysis of C programs. I have the following example C program dealing with simple lists of integers: ------------ start C example ------------- #include<stdlib.h> struct list_el { int val; struct list_el * next; }; typedef

This needs to be applied as well. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] GetElementPtr for packed types and VS build > Date: Wed, 01 Dec 2004 15:10:49 +0100 > > As I was working with packed types it became apparent that I sometimes >

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

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;

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:

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

Hi LLVM members, I have been working to make target independent memory layout for struct type(Aggregate type) in my team. I think that struct type has different memory layouts according to each target system in current LLVM. To implement target dependent concept for struct type, Frist, I have been implementing common type for struct type on bitcode at compilation time using llvm-gcc and then

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

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,

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

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

I'm currently using the below function from some library (MASS?) for writing my data out to file. I'm using it instead of plain old "write" because it does buffering. The problem that I'm having is that the numbers are space padded, but I need true tab-delineated files. It looks like the spaces are coming from 'format', but I don't see an option for format to

Hi, I found a mysterious behavior of LLVM optimizer. I compiled the following code by clang -emit-llvm -S: #include <stddef.h> static const struct t {char t[4]; char s;} p = {{}, 'a'}; char f() { return ((char*)&p)[offsetof(struct t, s)]; } then I obtained the following LLVM IR: %struct.t = type { [4 x i8], i8 } @p = constant %struct.t { [4 x i8] zeroinitializer, i8 97