similar to: [LLVMdev] About the result of getPointerSizeInBits();

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,

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

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, I found that llvm.exp.f32 didn't work but sqrt works well. I implemented a function like define inlinehint float "my_exp"(float %.value) { .body: %0 = call float @llvm.exp.f32(float %.value) ret float %0 } declare float @llvm.exp.f32(float) nounwind readonly But it generates following ASM: 00280072 movups xmm0,xmmword ptr [esp+8] 00280077 movss dword ptr

Hello guys, Thanks for your help when you are busing. I am working on an open source project. It supports shader language and I want JIT feature, so LLVM is used. But now I find the ABI & Calling Convention did not co-work with MSVC. For example, following code I have: struct float4 { float x, y, z, w; }; struct float4x4 { float4 x, y, z, w; }; float4 fetch_vs( float4x4* mat

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

I think I might have found a bug in the exection engine's 'constants folding'. Basically APInt's parameters are the wrong way round. Line 577 for lib/ExecutionEngine/ExecutionEngine.cpp :- case Instruction::PtrToInt: { GenericValue GV = getConstantValue(Op0); uint32_t PtrWidth = TD->getPointerSizeInBits(); GV.IntVal = APInt(PtrWidth,

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 into the structure. For example, when GEP works on the 5th element of the padded structure, it may in

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,

On 12/26/2010 01:31 AM, Eric Christopher wrote: >>>> >>>> >>>> The reason for the difference is that e.g "long" in >>>> >>>>> bool GOMP_loop_runtime_next(long, long) >>>> >>>> has a different size on different architectures. >>>> >>>> Currently we generate the prototypes and

>>> >>> >>> The reason for the difference is that e.g "long" in >>> >>>> bool GOMP_loop_runtime_next(long, long) >>> >>> has a different size on different architectures. >>> >>> Currently we generate the prototypes and functions ourselves: >>>> declare i8 @GOMP_loop_runtime_next(i64*,

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;

Aaron Gray wrote: > I think I might have found a bug in the exection engine's 'constants > folding'. > > Basically APInt's parameters are the wrong way round. > > Line 577 for lib/ExecutionEngine/ExecutionEngine.cpp :- > > case Instruction::PtrToInt: { > GenericValue GV = getConstantValue(Op0); > uint32_t PtrWidth =

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Dec 12, 2011 at 4:58 PM Subject: Re: [LLVMdev] GetElementPtr To: Eli Friedman <eli.friedman at gmail.com> Sorry, So what I'm trying to ask is are the widths given (32, 64) for the index and the offset the widths of the index and offset values or the width of the type they are

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

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: