search for: ptr11

Hi, Though I haven't looked into the implementation details, at the high level, I personally think having the address space argument is cleaner than having it encoded as a pointer. The memory barrier places a barrier on the entire address space. When I see the %ptr11 on the memory barrier instruction, my first instinct is to that it is a memory barrier on the region of memory that %ptr11 points to. What are other people opinions? -- Mon Ping On Jul 7, 2008, at 6:36 AM, Benedict Gaster wrote: > Thanks, I can now see that this can be implemented wi...

I agree that if we intend that the it is always a complete barrier, but it is possible for a more general memory fence operation that has the ability to place a barrier on the region of memory that %ptr11 points to but in the case that it does not point to a valid address then it is assumed to be a complete barrier for that address space. As sum types are not directly support in LLVM, then this semantics has to be supported with an additional argument describing which injection, i.e. if it...

On 2008-07-07, at 05:40, Benedict Gaster wrote: > %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* > %ptr0, i32 4) > %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* > %ptr11, i32 4) > call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, > i32 11, i1 false) ; force read-modify-write %ptr11 to complete > > A problem with this approach is that developing a new pass over the > IL that works with address spaces, will have to include knowled...

...ge of addresses? -- Mon Ping On Jul 7, 2008, at 12:21 PM, Benedict Gaster wrote: > I agree that if we intend that the it is always a complete barrier, > but it is possible for a more general memory fence operation that has > the ability to place a barrier on the region of memory that %ptr11 > points to but in the case that it does not point to a valid address > then it is assumed to be a complete barrier for that address space. As > sum types are not directly support in LLVM, then this semantics has to > be supported with an additional argument describing which injection,...

...Ben On 7 Jul 2008, at 13:43, Gordon Henriksen wrote: > On 2008-07-07, at 05:40, Benedict Gaster wrote: > >> %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* >> %ptr0, i32 4) >> %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* >> %ptr11, i32 4) >> call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, >> i32 11, i1 false) ; force read-modify-write %ptr11 to complete >> >> A problem with this approach is that developing a new pass over the >> IL that works with address spaces, will have...

...g > > > On Jul 7, 2008, at 12:21 PM, Benedict Gaster wrote: > >> I agree that if we intend that the it is always a complete barrier, >> but it is possible for a more general memory fence operation that has >> the ability to place a barrier on the region of memory that %ptr11 >> points to but in the case that it does not point to a valid address >> then it is assumed to be a complete barrier for that address space. >> As >> sum types are not directly support in LLVM, then this semantics has >> to >> be supported with an additional...

..., i1 <ss>, i32 addrspace, i1 <device> ) and we can now write the code: @llvm.atomic.load.add.p0i32 @llvm.atomic.load.add.p11i32 %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* %ptr0, i32 4) %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* %ptr11, i32 4) call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, i32 11, i1 false) ; force read-modify-write %ptr11 to complete A problem with this approach is that developing a new pass over the IL that works with address spaces, will have to include knowledge that for certain...

Hi, I got pulled off doing other things last week but I plan to get the support for address spaces to the intrinsics this week. As Benedict noted, the problem is that we don't carry the address space information with the intrinsics. Today, we will do an implicit cast to the default address space. My change will prevent that from happening by allowing the intrinsic to have a

..., at 12:21 PM, Benedict Gaster wrote: >> >>> I agree that if we intend that the it is always a complete barrier, >>> but it is possible for a more general memory fence operation that >>> has >>> the ability to place a barrier on the region of memory that %ptr11 >>> points to but in the case that it does not point to a valid address >>> then it is assumed to be a complete barrier for that address space. >>> As >>> sum types are not directly support in LLVM, then this semantics has >>> to >>> be supporte...

..., at 12:21 PM, Benedict Gaster wrote: >> >>> I agree that if we intend that the it is always a complete barrier, >>> but it is possible for a more general memory fence operation that >>> has >>> the ability to place a barrier on the region of memory that %ptr11 >>> points to but in the case that it does not point to a valid address >>> then it is assumed to be a complete barrier for that address space. >>> As >>> sum types are not directly support in LLVM, then this semantics has >>> to >>> be supporte...

...pair connections. BBV: selected pairs in the best tree for: %0 = load i8* %r.063, align 1, !tbaa !0 BBV: selected pair: %mul23 = mul nsw i32 %conv14, 234 <-> %mul35 = mul nsw i32 %conv15, 543 BBV: selected pair: %0 = load i8* %r.063, align 1, !tbaa !0 <-> %1 = load i8* %incdec.ptr11, align 1, !tbaa !0 BBV: selected pair: %conv14 = zext i8 %0 to i32 <-> %conv15 = zext i8 %1 to i32 BBV: selected pair: %add26 = add i32 %mul25, %mul23 <-> %add36 = add i32 %mul35, %mul33 BBV: selected pair: %mul = mul nsw i32 %conv14, 123 <-> %mul16 = mul nsw i32 %conv...

On Thu, 2012-01-26 at 15:12 -0600, Sebastian Pop wrote: > On Thu, Jan 26, 2012 at 2:49 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > Thanks! Did you compile with any non-default flags other than -mllvm > > -vectorize? > > I used -O3 and -vectorize, no other non-default flags. If I run clang -O3 -mllvm -vectorize -S -emit-llvm -o test.ll test.c then I get no

On Thu, Jan 26, 2012 at 3:41 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Thu, 2012-01-26 at 15:36 -0600, Sebastian Pop wrote: >> arm-none-linux-gnueabi > > Indeed, adding -ccc-host-triple arm-none-linux-gnueabi I also get Minor remark: please use -target instead of -ccc-host-triple that is now deprecated. Thanks for looking at this testcase. Sebastian -- Qualcomm

On Thu, 2012-01-26 at 15:36 -0600, Sebastian Pop wrote: > arm-none-linux-gnueabi Indeed, adding -ccc-host-triple arm-none-linux-gnueabi I also get vectorization (even though I don't get vectorization when targeting x86_64). I'll let you know what I find. -Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

...ounds i16* %nan, i32 1 store i16 0, i16* %nan, align 2, !tbaa !5 %incdec.ptr9 = getelementptr inbounds i16* %nan, i32 2 store i16 32767, i16* %incdec.ptr8, align 2, !tbaa !5 %incdec.ptr10 = getelementptr inbounds i16* %nan, i32 3 store i16 0, i16* %incdec.ptr9, align 2, !tbaa !5 %incdec.ptr11 = getelementptr inbounds i16* %nan, i32 4 store i16 -16384, i16* %incdec.ptr10, align 2, !tbaa !5 %incdec.ptr15 = getelementptr inbounds i16* %nan, i32 5 store i16 0, i16* %incdec.ptr11, align 2, !tbaa !5 %incdec.ptr15.1 = getelementptr inbounds i16* %nan, i32 6 store i16 0, i16* %incdec....