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 knowledge > that for certain operations address space information is encoded as > data rather than as types and in general, it may not be able to > statically determine the particular address space.It's quite possible to restrict an argument to an intrinsic to an immediate constant. See llvm.gcroot for an example. — Gordon
Thanks, I can now see that this can be implemented with Verifier.cpp. Even with this ability It is unclear that defining llvm.memory.barrier with an explicit address space argument is preferred over the llvm.memory.fence definition where the addrspace is encoded as part of the type as will be the case with the other atomic operations. What do you think? 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 to include knowledge >> that for certain operations address space information is encoded as >> data rather than as types and in general, it may not be able to >> statically determine the particular address space. > > It's quite possible to restrict an argument to an intrinsic to an > immediate constant. See llvm.gcroot for an example. > > — Gordon > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
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 with Verifier.cpp. > > Even with this ability It is unclear that defining llvm.memory.barrier > with an explicit address space argument is preferred over the > llvm.memory.fence definition where the addrspace is encoded as part of > the type as will be the case with the other atomic operations. What do > you think? > > 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 to include knowledge >>> that for certain operations address space information is encoded as >>> data rather than as types and in general, it may not be able to >>> statically determine the particular address space. >> >> It's quite possible to restrict an argument to an intrinsic to an >> immediate constant. See llvm.gcroot for an example. >> >> — Gordon >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev