[cfe-users] Memory accesses to struct variables in LLVM IR
Hi,
I'm using clang 3.4 to generate the bitcode of a C source file.
The source file is the following:
typedef struct __attribute__ ((__packed__)) { float x, y; } myType;
myType make_float2(float x, float y) { myType f = { x, y }; return f; }
int main(int argc, char* argv[])
{
myType myVar[5];
for(int i=0;i<5;i++)
myVar[i] = make_float2(i,i);
return(myVar[1].x);
}
The bitcode is generated using the following command:
clang -c -emit-llvm -O0 -fno-vectorize -fno-slp-vectorize
-fno-lax-vector-conversions main.c -o main.bc
target triple = "x86_64-unknown-linux-gnu"
%struct.myType = type <{ float, float }>
; Function Attrs: nounwind uwtable
define <2 x float> @_Z11make_float2ff(float %x, float %y) #0 {
entry:
%retval = alloca %struct.myType, align 1
%x1 = getelementptr inbounds %struct.myType* %retval, i32 0, i32 0
store float %x, float* %x1, align 1
%y2 = getelementptr inbounds %struct.myType* %retval, i32 0, i32 1
store float %y, float* %y2, align 1
%0 = bitcast %struct.myType* %retval to <2 x float>*
%1 = load <2 x float>* %0, align 1
ret <2 x float> %1
}
; Function Attrs: nounwind uwtable
define i32 @main(i32 %argc, i8** %argv) #0 {
entry:
%myVar = alloca [100 x %struct.myType], align 16
* %ref.tmp = alloca %struct.myType, align 1*
br label %for.cond
for.cond: ; preds = %for.inc, %entry
%i.0 = phi i32 [ 0, %entry ], [ %inc, %for.inc ]
%cmp = icmp slt i32 %i.0, 5
br i1 %cmp, label %for.body, label %for.end
for.body: ; preds = %for.cond
%idxprom = sext i32 %i.0 to i64
%arrayidx = getelementptr inbounds [100 x %struct.myType]* %myVar, i32 0,
i64 %idxprom
%conv = sitofp i32 %i.0 to float
%conv1 = sitofp i32 %i.0 to float
* %call = call <2 x float> @_Z11make_float2ff(float %conv, float %conv1)*
* %0 = bitcast %struct.myType* %ref.tmp to <2 x float>**
* store <2 x float> %call, <2 x float>* %0, align 1*
%1 = bitcast %struct.myType* %arrayidx to i8*
%2 = bitcast %struct.myType* %ref.tmp to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %1, i8* %2, i64 8, i32 1, i1
false)
br label %for.inc
for.inc: ; preds = %for.body
%inc = add nsw i32 %i.0, 1
br label %for.cond
for.end: ; preds = %for.cond
%arrayidx2 = getelementptr inbounds [100 x %struct.myType]* %myVar, i32
0, i64 1
%x = getelementptr inbounds %struct.myType* %arrayidx2, i32 0, i32 0
%3 = load float* %x, align 1
%conv3 = fptosi float %3 to i32
ret i32 %conv3
}
Looking at the C source code there should be 5 store instructions
corresponding to the 5 assignments of myVar[0], myVar[1], myVar[2],
myVar[3] and myVar[4].
When I look at the bitcode however, I see 5 instances of *store <2 x float>
%call, <2 x float>* %0, align 1 *which correspond to 5 stores at the same
address
of %0 (which is actually %ref.tmp defined as *%ref.tmp = alloca
%struct.myType, align 1*).
I would appreciate it if anyone could let me know how the 5 memory accesses
at the 5 *different* memory addresses are implemented in the bitcode.
Thanks,
Simona
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Memory accesses to struct variables in LLVM IR
Thanks, David, this is useful.
So sometimes the front-end generates llvm.memcpy instead of store
instructions.
Is there a rule in generating llvm.memcpy instructions instead of stores? I
would have the same question for other instrinsics, such as memset and
memmove.
Thanks,
Simona
On Thu, Feb 11, 2016 at 5:24 PM, David Blaikie wrote:
>
>
> On Thu, Feb 11, 2016 at 7:25 AM, Simona Simona via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>> Hi,
>>
>> I'm using clang 3.4 to generate the bitcode of a C source file.
>> The source file is the following:
>>
>> typedef struct __attribute__ ((__packed__)) { float x, y; } myType;
>> myType make_float2(float x, float y) { myType f = { x, y }; return f; }
>>
>> int main(int argc, char* argv[])
>> {
>> myType myVar[5];
>>
>> for(int i=0;i<5;i++)
>> myVar[i] = make_float2(i,i);
>>
>> return(myVar[1].x);
>> }
>>
>> The bitcode is generated using the following command:
>> clang -c -emit-llvm -O0 -fno-vectorize -fno-slp-vectorize
>> -fno-lax-vector-conversions main.c -o main.bc
>>
>> target triple = "x86_64-unknown-linux-gnu"
>>
>> %struct.myType = type <{ float, float }>
>>
>> ; Function Attrs: nounwind uwtable
>> define <2 x float> @_Z11make_float2ff(float %x, float %y) #0 {
>> entry:
>> %retval = alloca %struct.myType, align 1
>> %x1 = getelementptr inbounds %struct.myType* %retval, i32 0, i32 0
>> store float %x, float* %x1, align 1
>> %y2 = getelementptr inbounds %struct.myType* %retval, i32 0, i32 1
>> store float %y, float* %y2, align 1
>> %0 = bitcast %struct.myType* %retval to <2 x float>*
>> %1 = load <2 x float>* %0, align 1
>> ret <2 x float> %1
>> }
>>
>> ; Function Attrs: nounwind uwtable
>> define i32 @main(i32 %argc, i8** %argv) #0 {
>> entry:
>> %myVar = alloca [100 x %struct.myType], align 16
>>
>
> Looks like your IR corresponds to an array of length 100, not 5 as in your
> source, but that's not too important
>
>
>> * %ref.tmp = alloca %struct.myType, align 1*
>> br label %for.cond
>>
>> for.cond: ; preds = %for.inc,
>> %entry
>> %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.inc ]
>> %cmp = icmp slt i32 %i.0, 5
>> br i1 %cmp, label %for.body, label %for.end
>>
>> for.body: ; preds = %for.cond
>> %idxprom = sext i32 %i.0 to i64
>> %arrayidx = getelementptr inbounds [100 x %struct.myType]* %myVar, i32
>> 0, i64 %idxprom
>> %conv = sitofp i32 %i.0 to float
>> %conv1 = sitofp i32 %i.0 to float
>> * %call = call <2 x float> @_Z11make_float2ff(float %conv, float
>> %conv1)*
>> * %0 = bitcast %struct.myType* %ref.tmp to <2 x float>**
>> * store <2 x float> %call, <2 x float>* %0, align 1*
>> %1 = bitcast %struct.myType* %arrayidx to i8*
>> %2 = bitcast %struct.myType* %ref.tmp to i8*
>> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %1, i8* %2, i64 8, i32 1, i1
>> false)
>>
>
> Here is the store ^ into your array (%1 is the destination, a bitcast of
> %arrayidx, which is the pointer into your array at index %idxprom, which is
> %i.0, etc) using the memcpy intrinsic, rather than a store instruction.
>
>
>> br label %for.inc
>>
>> for.inc: ; preds = %for.body
>> %inc = add nsw i32 %i.0, 1
>> br label %for.cond
>>
>> for.end: ; preds = %for.cond
>> %arrayidx2 = getelementptr inbounds [100 x %struct.myType]* %myVar, i32
>> 0, i64 1
>> %x = getelementptr inbounds %struct.myType* %arrayidx2, i32 0, i32 0
>> %3 = load float* %x, align 1
>> %conv3 = fptosi float %3 to i32
>> ret i32 %conv3
>> }
>>
>> Looking at the C source code there should be 5 store instructions
>> corresponding to the 5 assignments of myVar[0], myVar[1], myVar[2],
>> myVar[3] and myVar[4].
>> When I look at the bitcode however, I see 5 instances of *store <2 x
>> float> %call, <2 x float>* %0, align 1 *which correspond to 5 stores at
>> the same address
>> of %0 (which is actually %ref.tmp defined as *%ref.tmp = alloca
>> %struct.myType, align 1*).
>>
>> I would appreciate it if anyone could let me know how the 5 memory
>> accesses at the 5 *different* memory addresses are implemented in the
>> bitcode.
>>
>> Thanks,
>> Simona
>>
>>
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Memory accesses to struct variables in LLVM IR
Thanks, David, I understand. Then, is there a way of disabling generating
the llvm. intrinsics? opt seems to have an option called
-disable-simplify-libcalls. However, in my case, it does not remove the
llvm.memcpy instruction from the bitcode.
On Thu, Feb 11, 2016 at 6:04 PM, David Blaikie wrote:
> There probably is a rule, but I don't know what it is - I would imagine
> memcpy is used when storing a whole aggregate (but then you'll get into ABI
> issues, etc - maybe if the struct contains only a single primitive type it
> just switches to a store, etc).
>
> On Thu, Feb 11, 2016 at 8:44 AM, Simona Simona > wrote:
>
>> Thanks, David, this is useful.
>>
>> So sometimes the front-end generates llvm.memcpy instead of store
>> instructions.
>> Is there a rule in generating llvm.memcpy instructions instead of stores?
>> I would have the same question for other instrinsics, such as memset and
>> memmove.
>>
>> Thanks,
>> Simona
>>
>> On Thu, Feb 11, 2016 at 5:24 PM, David Blaikie
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 11, 2016 at 7:25 AM, Simona Simona via cfe-users <
>>> cfe-users@lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm using clang 3.4 to generate the bitcode of a C source file.
>>>> The source file is the following:
>>>>
>>>> typedef struct __attribute__ ((__packed__)) { float x, y; } myType;
>>>> myType make_float2(float x, float y) { myType f = { x, y }; return f; }
>>>>
>>>> int main(int argc, char* argv[])
>>>> {
>>>> myType myVar[5];
>>>>
>>>> for(int i=0;i<5;i++)
>>>> myVar[i] = make_float2(i,i);
>>>>
>>>> return(myVar[1].x);
>>>> }
>>>>
>>>> The bitcode is generated using the following command:
>>>> clang -c -emit-llvm -O0 -fno-vectorize -fno-slp-vectorize
>>>> -fno-lax-vector-conversions main.c -o main.bc
>>>>
>>>> target triple = "x86_64-unknown-linux-gnu"
>>>>
>>>> %struct.myType = type <{ float, float }>
>>>>
>>>> ; Function Attrs: nounwind uwtable
>>>> define <2 x float> @_Z11make_float2ff(float %x, float %y) #0 {
>>>> entry:
>>>> %retval = alloca %struct.myType, align 1
>>>> %x1 = getelementptr inbounds %struct.myType* %retval, i32 0, i32 0
>>>> store float %x, float* %x1, align 1
>>>> %y2 = getelementptr inbounds %struct.myType* %retval, i32 0, i32 1
>>>> store float %y, float* %y2, align 1
>>>> %0 = bitcast %struct.myType* %retval to <2 x float>*
>>>> %1 = load <2 x float>* %0, align 1
>>>> ret <2 x float> %1
>>>> }
>>>>
>>>> ; Function Attrs: nounwind uwtable
>>>> define i32 @main(i32 %argc, i8** %argv) #0 {
>>>> entry:
>>>> %myVar = alloca [100 x %struct.myType], align 16
>>>>
>>>
>>> Looks like your IR corresponds to an array of length 100, not 5 as in
>>> your source, but that's not too important
>>>
>>>
>>>> * %ref.tmp = alloca %struct.myType, align 1*
>>>> br label %for.cond
>>>>
>>>> for.cond: ; preds = %for.inc,
>>>> %entry
>>>> %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.inc ]
>>>> %cmp = icmp slt i32 %i.0, 5
>>>> br i1 %cmp, label %for.body, label %for.end
>>>>
>>>> for.body: ; preds = %for.cond
>>>> %idxprom = sext i32 %i.0 to i64
>>>> %arrayidx = getelementptr inbounds [100 x %struct.myType]* %myVar,
>>>> i32 0, i64 %idxprom
>>>> %conv = sitofp i32 %i.0 to float
>>>> %conv1 = sitofp i32 %i.0 to float
>>>> * %call = call <2 x float> @_Z11make_float2ff(float %conv, float
>>>> %conv1)*
>>>> * %0 = bitcast %struct.myType* %ref.tmp to <2 x float>**
>>>> * store <2 x float> %call, <2 x float>* %0, align 1*
>>>> %1 = bitcast %struct.myType* %arrayidx to i8*
>>>> %2 = bitcast %struct.myType* %ref.tmp to i8*
>>>> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %1, i8* %2, i64 8, i32 1, i1
>>>> false)
>>>>
>>>
>>> Here is the store ^ into your array (%1 is the destination, a bitcast of
>>> %arrayidx, which is the
[cfe-users] PointerTy and VectorTy
Hello, I'm using LLVM 3.4 and have the following IR instruction: %tmp1 = load *<2 x float>** %tmp, align 1, !dbg !26 The operand 0 of the load instruction is of type PointerType. I've checked this using: I.getOperand(0)->getType()->isPointerTy(). I would appreciate if someone could tell me how I could extract from this PointerType operand the vector size (2) and the scalar type (float). Many thanks, Simona ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Binary instruction operand type - Fast-math-flags - Vectorized IR code
Hello, I'm using LLVM 3.4 and noticed that some of the IR binary instructions have the following format: = frem [fast-math flags]* , ; yields ty:result I'm mainly interested in extracting the type of the operands, regardless of whether the fast-math-flags are set or not. In the case above, that would be floating-point or vector. Q1. I was just wondering if doing I.getOperand(0)->getType() would be sufficient to extract the operands type. Q2. Moreover, how can you extract the fast-math-flags? Q3. I'd also appreciate it if someone could tell me what C/C++ source code should I use to generate IR code that includes some binary operation(s) with vector operands. Many thanks, Simona ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Fwd: Binary instruction operand type - Fast-math-flags - Vectorized IR code
Hello, I'd appreciate it if someone could give me some hints on my questions below. Many thanks, Simona -- Forwarded message -- From: Simona Simona Date: Mon, Feb 29, 2016 at 11:09 AM Subject: Binary instruction operand type - Fast-math-flags - Vectorized IR code To: cfe-users@lists.llvm.org Hello, I'm using LLVM 3.4 and noticed that some of the IR binary instructions have the following format: = frem [fast-math flags]* , ; yields ty:result I'm mainly interested in extracting the type of the operands, regardless of whether the fast-math-flags are set or not. In the case above, that would be floating-point or vector. Q1. I was just wondering if doing I.getOperand(0)->getType() would be sufficient to extract the operands type. I've tried it and I get a TokenTyID for a float operand. Q2. Moreover, how can one extract the fast-math-flags? Q3. I'd also appreciate it if someone could tell me what C/C++ source code should I use to generate IR code that includes some binary operation(s) with vector operands. Many thanks, Simona ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] LLVM 3.8.0 - Adding new instruction to a basic block
Hello, I'm trying to add a new instruction after a given instruction in a basic block. Until LLVM 3.7, I was using the following code: BB->getInstList().insertAfter(I, new_inst); [where both I and new_inst are Instruction*] In LLVM 3.8 however, the SymbolTableList was created as a wrapper over iplist. Could anyone please tell me how I can do the same type of insertion in LLVM 3.8? Thank you and Regards, Simona ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
