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
Hi Mon Ping, Sorry for the slow reply but I have been out on vacation. Originally I thought that Sun's latest ISAs support barriers with explicit address but looking at this now I cannot find a reference to this and so agree that this may be a useful feature at this time. One area where this may be useful in the future is with regard to the memory model that C++ is considering, it allows specific variables to be type atomic<T> that can be accessed in a relaxed manner (by default access is not relaxed). In this case fence operations will be required, possibly at the granularity of a single variable access. I agree that there does not seem a strong argument for the more general memory fence operation and given the not very nice semantics, it would make sense to go with something along the lines of a barrier operation with an (optional) memory space argument. Is it your intention to add a generalized version along with your changes for supporting intrinsics with address spaces? Ben On 7 Jul 2008, at 22:24, Mon P Wang wrote:> 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hi Ben, Vacation is always a good thing. Hope you had a good one. In my mind, having a more general memory consistency model is going to be very useful in LLVM in the future. It is still a little unclear to me what we should support. I haven't looked at what C++ is considering for their model. Are they going to support different relaxations models like relaxing write to read or write order, read others and write early? In terms of what I'm doing now, I was planning to put in intrinsics with memory spaces first and then later on add in the memory barrier that takes an optional memory space argument. BTW, for the name of the intrinsics, it was simpler to define the intrinsic names to be return type followed by any parameter, e.g., @llvm.atomic.load.add.i32.p0i32 // returns i32, i32 ptr to default address space @llvm.atomic.load.add.i32.p11i32 // return i32, i32 ptr to address space 11 -- Mon Ping On Jul 14, 2008, at 2:58 AM, Benedict Gaster wrote:> Hi Mon Ping, > > Sorry for the slow reply but I have been out on vacation. > > Originally I thought that Sun's latest ISAs support barriers with > explicit address but looking at this now I cannot find a reference to > this and so agree that this may be a useful feature at this time. One > area where this may be useful in the future is with regard to the > memory model that C++ is considering, it allows specific variables to > be type atomic<T> that can be accessed in a relaxed manner (by default > access is not relaxed). In this case fence operations will be > required, possibly at the granularity of a single variable access. > > I agree that there does not seem a strong argument for the more > general memory fence operation and given the not very nice semantics, > it would make sense to go with something along the lines of a barrier > operation with an (optional) memory space argument. Is it your > intention to add a generalized version along with your changes for > supporting intrinsics with address spaces? > > Ben > > On 7 Jul 2008, at 22:24, Mon P Wang wrote: > >> 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 >> >> _______________________________________________ >> 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