search for: coerce0

...9; > target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" > target triple = "x86_64-apple-macosx10.10.0" > > ; Function Attrs: nounwind readnone ssp uwtable > define { <2 x float>, float } @_Z18sampleNullOperator5PointS_(i64 %pmin.coerce0, i32 %pmin.coerce1, i64 %pmax.coerce0, i32 %pmax.coerce1) #0 { > _ZN15SamplingClosureD1Ev.exit: > %0 = icmp sgt i32 %pmin.coerce1, %pmax.coerce1 > ret { <2 x float>, float } zeroinitializer > } > > attributes #0 = { nounwind readnone ssp uwtable &quo...

...i64:64-f80:128-n8:16:32:64-S128" >> > target triple = "x86_64-apple-macosx10.10.0" >> > >> > ; Function Attrs: nounwind readnone ssp uwtable >> > define { <2 x float>, float } @_Z18sampleNullOperator5PointS_(i64 >> %pmin.coerce0, i32 %pmin.coerce1, i64 %pmax.coerce0, i32 %pmax.coerce1) #0 >> { >> > _ZN15SamplingClosureD1Ev.exit: >> > %0 = icmp sgt i32 %pmin.coerce1, %pmax.coerce1 >> > ret { <2 x float>, float } zeroinitializer >> > } >> > >>...

...e byval %in) nounwind readonly { entry: %val = getelementptr inbounds %struct.myType* %in, i64 0, i32 0 %0 = load i64* %val, align 8, !tbaa !0 %conv = trunc i64 %0 to i32 ret i32 %conv } [ABIArgInfo::getExtend(), ABIArgInfo::getDirect(), ABIArgInfo::getExpand()] define i32 @convert(i64 %in.coerce0) nounwind readnone { entry: %conv = trunc i64 %in.coerce0 to i32 ret i32 %conv } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120613/70b200dc/attachment.html>

...i64, i32, i32 } define signext i32 @ppc64le_func([2 x i64] %r.coerce) #0 { entry: %r = alloca %struct.record, align 8 %0 = bitcast %struct.record* %r to [2 x i64]* store [2 x i64] %r.coerce, [2 x i64]* %0, align 8 .... for x86_64 define i32 @x86_64_func(i64 %r.coerce0, i64 %r.coerce1) #0 { entry: %r = alloca %struct.record, align 8 %0 = bitcast %struct.record* %r to { i64, i64 }* %1 = getelementptr inbounds { i64, i64 }, { i64, i64 }* %0, i32 0, i32 0 store i64 %r.coerce0, i64* %1, align 8 %2 = getelementptr inbounds { i64, i64...

...markers in the right places, or byval, or any of that > sort of stuff it has to do today. > Clang's ABI lowering is part of why I don't want to pattern match alloca+store in LLVM. Today here is how we pass 'struct P { double x, y; }' on x86_64-linux: define void @f(double %p.coerce0, double %p.coerce1) #0 { entry: %p = alloca %struct.P, align 8 %0 = bitcast %struct.P* %p to { double, double }* %1 = getelementptr inbounds { double, double }, { double, double }* %0, i32 0, i32 0 store double %p.coerce0, double* %1, align 8 %2 = getelementptr inbounds { double, double }...

...**** > > %0 = load i64* %val, align 8, !tbaa !0**** > > %conv = trunc i64 %0 to i32**** > > ret i32 %conv**** > > }**** > > ** ** > > [ABIArgInfo::getExtend(), ABIArgInfo::getDirect(), ABIArgInfo::getExpand()] > **** > > define i32 @convert(i64 %in.coerce0) nounwind readnone {**** > > entry:**** > > %conv = trunc i64 %in.coerce0 to i32**** > > ret i32 %conv**** > > }**** > > ** ** > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llv...

...rkitem.id.x() #0, !range !11 > %7 = tail call i32 @llvm.amdgcn.workgroup.id.x() #0 > %mul.i.i.i.i.i = mul nsw i32 %7, %3 > %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6 > %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64 > %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64 %idxprom.i.i.i, !amdgpu.uniform !12, !amdgpu.noclobber !12 > > However since this depends on workitem.id <http://workitem.id/>.x, it certainly is not > > -Matt Actually you have the amdgpu.uniform annotation already here, and it isn’t added by the backend optimization pass...

...nelIZL12test_barrieriPPcE3$_0EEvT_': DIVERGENT: %6 = tail call i32 @llvm.amdgcn.workitem.id.x() #0, !range !11 DIVERGENT: %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6 DIVERGENT: %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64 DIVERGENT: %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64 %idxprom.i.i.i DIVERGENT: %9 = load i32, i32 addrspace(1)* %8, align 4 DIVERGENT: %10 = getelementptr [16 x i32], [16 x i32] addrspace(3)* @"_ZN5pacxx2v213genericKernelIZL12test_barrieriPPcE3$_0EEvT__sm0", i32 0, i32 %6 DIVERGENT: store i32 %9, i32 addrspace(3)* %10, align 4 DIVER...

On Fri, Dec 9, 2016 at 1:30 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/9/2016 8:45 AM, Reid Kleckner wrote: > > On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> So IIUC basically the *only* reason for this IR change is that we don’t >> want to pattern match in debug build? >> I don't

...target-specific C-ABI compatible function signature using LLVM? For example, this C-Code:     typedef struct vpt_data {         char x;         int a;         char c;         float b;     } vpt_data;         void vpt_test( vpt_data vd ) { Generates a function:     define void @vpt_test(i64 %vd.coerce0, i64 %vd.coerce1) #0 { And also packs/unpacks the structure values when calling/being called. If I create the function signature `vpt_test( vpt_data vd)` in LLVM however, it will just pass the structure as is to the function (push on stack I presume). This means I can't call any C functions t...

Hi dev list, I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some strange behavior of the AMDGPU backend. The following IR is generated for a simple address space test that copies from global to shared memory and back to global after a barrier synchronization. Here is the IR is attached as as1.ll The output is as follows: 0 0 0 0 0 0 0 0 0 0 0 0 0

Hi Dmitri, Regarding your first question, if you can use the MCJIT engine a caching mechanism will be available very soon. I'm preparing to commit a patch today to add this capability. I'm not sure what it would take to get something similar working with the older JIT engine. I expect it would take a fair amount of work because the older JIT engine isn't designed around object

Hi all, For my current project I need a couple of informations about JIT. I seen similar questions already, but the answers are a bit older and I hope somebody can provide me a recent information. 1. In my project I frequently construct LLVM IR, compile it and execute with JIT. Because the constructed IR is often the same (but can vary depending on input data) I would like to cache produced