[LLVMdev] addrspace attribute and intrisics

[Benedict Gaster]

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
>