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
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 is a valid address or not, the type of %ptr11 is passed. Ben On 7 Jul 2008, at 17:15, Mon P Wang wrote:> g 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?
Hi Ben,
Sorry, I didn't read carefully enough your point on a generic memory
fence. I don't like the semantics that the compiler needs to
determine if a pointer has a valid address or not to determine the
semantics of the operation. In your original email, you indicate you
propose another field "barrier" that indicates if the barrier applies
to the entire space that the pointer points to or to the location that
ptr points to, i.e.,
declare void @llvm.memory.fence( i1 <ll>, i1 <ls>, i1 <sl>,
i1 <ss>,
i32
addrspace(11)*<ptr>, i1 <device>, i1 barrier )
That would work but I don't particular like it. It seems cleaner if we
could overload the signature such that if given an integer, it treats
it as a barrier for the address space or if we given a pointer, we can
treat it as a barrier to that location.
One question that I have is what are the typical use cases for the
more generic memory barrier. Do current hardware support barrier on a
particular element or do they specify it for a range 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,
> i.e. if it is a valid address or not, the type of %ptr11 is passed.
>
> Ben
>
>
> On 7 Jul 2008, at 17:15, Mon P Wang wrote:
>
>> g 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?
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev