[LLVMdev] addrspace attribute and intrisics

[Mon P Wang]

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