addrspace attribute and intrisics

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

addrspace attribute and intrisics

Gaster, Benedict
I am slightly unclear about the semantics of the addrspace attribute and there use with intrinsics. For example, is the following code valid:

%ptr      = malloc i32 addrspace(11)
%result = call i32 @llvm.atomic.load.add.i32( i32 addrspace(11)* %ptr, i32 4);

If this is valid it means that a certain amount of type information is lost at the LLVM IL level and if it is not valid, then it is impossible to use any of the built-in functions for anything other than the default address space. 

Ben

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Chris Lattner
On Thu, 3 Jul 2008, Benedict Gaster wrote:

> I am slightly unclear about the semantics of the addrspace attribute and
> there use with intrinsics. For example, is the following code valid:
>
> % ptr      = malloc i32 addrspace(11)
> % result = call i32 @llvm.atomic.load.add.i32( i32 addrspace(11)* %ptr,
> i32 4);
>
> If this is valid it means that a certain amount of type information is lost
> at the LLVM IL level and if it is not valid, then it is impossible to use any
> of the built-in functions for anything other than the default address space.

That is not currently supported, but Mon Ping is working on it (as I
understand).  Mon Ping, are you still working on this?  If so, what is the
status?

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Mon Ping Wang
Hi,

I got pulled off doing other things last week but I plan to get the  
support for address spaces to the intrinsics this week. As Benedict  
noted, the problem is that we don't carry the address space  
information with the intrinsics.  Today, we will do an implicit cast  
to the default address space.  My change will prevent that from  
happening by allowing the intrinsic to have a signature with an  
address qualified pointer.   This will change the name of the  
intrinsics.  When I talked to Dan about this, we thought it made sense  
to add a pointer qualifier to the name.  For example, the name of the  
atomic add will change from @llvm.atomic.load.add.i32 to
    @llvm.atomic.load.add.p0i32     // i32 ptr to default address space
    @llvm.atomic.load.add.p11i32   // i32 ptr to address space 11

This means we will auto convert the old names to the new one.   I'm  
also planning to change clang to generate an error if the compiler  
implicitly cast a pointer between two different address spaces.  If  
anyone has an issue or concerns, please let me know.

   -- Mon Ping


On Jul 3, 2008, at 10:11 AM, Chris Lattner wrote:

> On Thu, 3 Jul 2008, Benedict Gaster wrote:
>> I am slightly unclear about the semantics of the addrspace  
>> attribute and there use with intrinsics. For example, is the  
>> following code valid:
>>
>> % ptr      = malloc i32 addrspace(11)
>> % result = call i32 @llvm.atomic.load.add.i32( i32 addrspace(11)*  
>> %ptr, i32 4);
>>
>> If this is valid it means that a certain amount of type information  
>> is lost at the LLVM IL level and if it is not valid, then it is  
>> impossible to use any of the built-in functions for anything other  
>> than the default address space.
>
> That is not currently supported, but Mon Ping is working on it (as I  
> understand).  Mon Ping, are you still working on this?  If so, what  
> is the status?
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Gaster, Benedict
Hi,

Great I look forward to the patch!

One comment I had was on the name of the overloaded intrinsics. In  
your example you resolve the atomic.load.add to:

        @llvm.atomic.load.add.p0i32     // i32 ptr to default address space
        @llvm.atomic.load.add.p11i32   // i32 ptr to address space 11

and I was wondering could they instead be named:

        @llvm.atomic.load.add.p0.i32     // i32 ptr to default address space
        @llvm.atomic.load.add.p11.i32   // i32 ptr to address space 11

For me this is a little easier to read and separates out the type  
components.  I expect that there might be an LLVM naming convention  
that I am not aware off, that invalidates my suggestion.

Given these changes enable atomics with the ability to work on  
different address spaces, there becomes the need to be able to express  
barriers for these different address spaces. The problem is that the  
current barrier operation does not provide enough granularity:
        declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1  
<ss>, i1 <device> )
I was wondering if this would be possible to fix?  One possible  
solution to this is to provide an additional argument which ranges  
over valid address spaces, e.g.:
        declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1  
<ss>, i32 addrspace, i1 <device> )
and we can now write the code:
        @llvm.atomic.load.add.p0i32
        @llvm.atomic.load.add.p11i32

         %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. An alternative is to  
generalize the barrier operation to a more general memory fence, that  
as a special case reduces to the above barrier, e.g.:
        declare void @llvm.memory.fence( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>,  
i32 addrspace(11)*<ptr>, i1 <device>, i1 barrier )
The code above then becomes:
        @llvm.atomic.load.add.p0i32
        @llvm.atomic.load.add.p11i32

         %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.fence(i1 true, i1 true, i1 false, i1 false,  
i32 addrspace(11)* %ptr11, i1 false, i1 true)

If a particular target supports fence operations with explicit  
addresses the last line could be replaced with the more fine grained:

        call void @llvm.memory.fence(i1 true, i1 true, i1 false, i1 false,  
i32 addrspace(11)* %ptr11, i1 false, i1 false)
Does this make sense or have I missed something that would enable the  
existing llvm.memory.barrier operation to be used in the context of  
address spaces?

Ben

On 5 Jul 2008, at 21:33, Mon P Wang wrote:

> Hi,
>
> I got pulled off doing other things last week but I plan to get the
> support for address spaces to the intrinsics this week. As Benedict
> noted, the problem is that we don't carry the address space
> information with the intrinsics.  Today, we will do an implicit cast
> to the default address space.  My change will prevent that from
> happening by allowing the intrinsic to have a signature with an
> address qualified pointer.   This will change the name of the
> intrinsics.  When I talked to Dan about this, we thought it made sense
> to add a pointer qualifier to the name.  For example, the name of the
> atomic add will change from @llvm.atomic.load.add.i32 to
>    @llvm.atomic.load.add.p0i32     // i32 ptr to default address space
>    @llvm.atomic.load.add.p11i32   // i32 ptr to address space 11
>
> This means we will auto convert the old names to the new one.   I'm
> also planning to change clang to generate an error if the compiler
> implicitly cast a pointer between two different address spaces.  If
> anyone has an issue or concerns, please let me know.
>
>   -- Mon Ping
>
>
> On Jul 3, 2008, at 10:11 AM, Chris Lattner wrote:
>
>> On Thu, 3 Jul 2008, Benedict Gaster wrote:
>>> I am slightly unclear about the semantics of the addrspace
>>> attribute and there use with intrinsics. For example, is the
>>> following code valid:
>>>
>>> % ptr      = malloc i32 addrspace(11)
>>> % result = call i32 @llvm.atomic.load.add.i32( i32 addrspace(11)*
>>> %ptr, i32 4);
>>>
>>> If this is valid it means that a certain amount of type information
>>> is lost at the LLVM IL level and if it is not valid, then it is
>>> impossible to use any of the built-in functions for anything other
>>> than the default address space.
>>
>> That is not currently supported, but Mon Ping is working on it (as I
>> understand).  Mon Ping, are you still working on this?  If so, what
>> is the status?
>>
>> -Chris
>>
>> --
>> http://nondot.org/sabre/
>> http://llvm.org/
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Gordon Henriksen-3
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Gaster, Benedict
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Mon Ping Wang
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
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Mon Ping Wang
In reply to this post by Gaster, Benedict
Hi,

I should double check this but I viewed the "." as being useful to  
separate different parameter types in case we need to overload on  
multiple parameters.  I think of p0i32 as the type of a single  
parameter.  If we had multiple parameters with complex types, I think  
it might become harder to read if we separated each component, .e.g.,  
a hypothetical intrinsic that takes a vector of 4 of pointers to i32  
and vector of 4 of pointers to i64 would look either like
    @intrinsic.v4p0i32.v4p0i64
or
    @intrinsic.v4.p0.i32.v4.p0.i64

I find the former a little easier to parse.  What do you all think?

   -- Mon Ping


On Jul 7, 2008, at 2:40 AM, Benedict Gaster wrote:

> Hi,
>
> Great I look forward to the patch!
>
> One comment I had was on the name of the overloaded intrinsics. In
> your example you resolve the atomic.load.add to:
>
> @llvm.atomic.load.add.p0i32     // i32 ptr to default address space
> @llvm.atomic.load.add.p11i32   // i32 ptr to address space 11
>
> and I was wondering could they instead be named:
>
> @llvm.atomic.load.add.p0.i32     // i32 ptr to default address space
> @llvm.atomic.load.add.p11.i32   // i32 ptr to address space 11
>
> For me this is a little easier to read and separates out the type
> components.  I expect that there might be an LLVM naming convention
> that I am not aware off, that invalidates my suggestion.
> [Deleted Text]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Chris Lattner
On Mon, 7 Jul 2008, Mon P Wang wrote:

> I should double check this but I viewed the "." as being useful to
> separate different parameter types in case we need to overload on
> multiple parameters.  I think of p0i32 as the type of a single
> parameter.  If we had multiple parameters with complex types, I think
> it might become harder to read if we separated each component, .e.g.,
> a hypothetical intrinsic that takes a vector of 4 of pointers to i32
> and vector of 4 of pointers to i64 would look either like
>    @intrinsic.v4p0i32.v4p0i64
> or
>    @intrinsic.v4.p0.i32.v4.p0.i64
>
> I find the former a little easier to parse.  What do you all think?

I agree, I prefer the former.

-Chris

> On Jul 7, 2008, at 2:40 AM, Benedict Gaster wrote:
>
>> Hi,
>>
>> Great I look forward to the patch!
>>
>> One comment I had was on the name of the overloaded intrinsics. In
>> your example you resolve the atomic.load.add to:
>>
>> @llvm.atomic.load.add.p0i32     // i32 ptr to default address space
>> @llvm.atomic.load.add.p11i32   // i32 ptr to address space 11
>>
>> and I was wondering could they instead be named:
>>
>> @llvm.atomic.load.add.p0.i32     // i32 ptr to default address space
>> @llvm.atomic.load.add.p11.i32   // i32 ptr to address space 11
>>
>> For me this is a little easier to read and separates out the type
>> components.  I expect that there might be an LLVM naming convention
>> that I am not aware off, that invalidates my suggestion.
>> [Deleted Text]
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Gaster, Benedict
Yes I agree now that I've seen a more complex example.

Ben

On 7 Jul 2008, at 20:27, Chris Lattner wrote:

> On Mon, 7 Jul 2008, Mon P Wang wrote:
>> I should double check this but I viewed the "." as being useful to
>> separate different parameter types in case we need to overload on
>> multiple parameters.  I think of p0i32 as the type of a single
>> parameter.  If we had multiple parameters with complex types, I think
>> it might become harder to read if we separated each component, .e.g.,
>> a hypothetical intrinsic that takes a vector of 4 of pointers to i32
>> and vector of 4 of pointers to i64 would look either like
>>   @intrinsic.v4p0i32.v4p0i64
>> or
>>   @intrinsic.v4.p0.i32.v4.p0.i64
>>
>> I find the former a little easier to parse.  What do you all think?
>
> I agree, I prefer the former.
>
> -Chris
>
>> On Jul 7, 2008, at 2:40 AM, Benedict Gaster wrote:
>>
>>> Hi,
>>>
>>> Great I look forward to the patch!
>>>
>>> One comment I had was on the name of the overloaded intrinsics. In
>>> your example you resolve the atomic.load.add to:
>>>
>>> @llvm.atomic.load.add.p0i32     // i32 ptr to default address space
>>> @llvm.atomic.load.add.p11i32   // i32 ptr to address space 11
>>>
>>> and I was wondering could they instead be named:
>>>
>>> @llvm.atomic.load.add.p0.i32     // i32 ptr to default address  
>>> space
>>> @llvm.atomic.load.add.p11.i32   // i32 ptr to address space 11
>>>
>>> For me this is a little easier to read and separates out the type
>>> components.  I expect that there might be an LLVM naming convention
>>> that I am not aware off, that invalidates my suggestion.
>>> [Deleted Text]
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Gaster, Benedict
In reply to this post by Mon Ping Wang
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Mon Ping Wang
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Gaster, Benedict
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
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Mon Ping 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
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Gaster, Benedict
Hi Mon Wang,

As I understand it the C++0x memory model will, by default, be similar
to Java's in that it will assume sequential consistency, using
acquire/release atomics (similar to Java's volatile), for all programs
that do not contain data races. Unlike Java in the case when a program
contains a data race, the program behavior is undefined. Adopting this
model allows many sequential compiler optimizations to be applied within
the context of a single thread; although register optimizations, such as
promotion, are not always valid. Of course, the problem with this
approach is that it is often the case that compiler/hardware cannot
reorder accesses to gain optimal performance and in light of this C++0x
allows values of type atomic to be accessed through a relaxed
consistency model, e.g.

        x.load(memory_order_relaxed);
        x.store(something, memory_order_relaxed);

In this case the compiler is free to order load/stores to x, in
different threads, any why it feels fit. The full set of relaxed options
are defined by the enumeration:

        typedef enum memory_order {
      memory_order_relaxed, memory_order_acquire,
memory_order_release,
      memory_order_acq_rel, memory_order_seq_cst
        } memory_order;

In the case of a default consistency model memory fences are not
required but, in general, this is no longer the case for the relaxed
model and C++ provides a family of fence operations, one per type of
atomic (i.e. bool, address, and integral types); the bool fence
operation is declared as:

        void atomic_fence( const volatile atomic_bool*, memory_order );

One interesting point is that C++0x defines fences for operations and
not just load and stores. I am not completely sure of the implications
with respect to mapping to LLVM but note that this is relaxed a little
by providing per-variable fence operations, implemented as
read-modify-write instructions, which is similar to those provided by
LLVM.

Anyway I have probably strayed of topic for this list and so will stop
now.

Ben

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Mon P Wang
Sent: Tuesday, July 15, 2008 6:18 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] addrspace attribute and intrisics

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
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

David Vandevoorde
If you're interested in the evolution of C++'s memory model, here are  
some papers on the topic:

        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm
        http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm
        http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html

A working draft for the next C++ standard is also available:

        http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf

(It incorporates some of the memory model changes.)

        Daveed

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Mon Ping Wang
Thanks for the pointers.

  -- Mon Ping

On Jul 15, 2008, at 7:57 AM, David Vandevoorde wrote:

> If you're interested in the evolution of C++'s memory model, here are
> some papers on the topic:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html
>
> A working draft for the next C++ standard is also available:
>
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf
>
> (It incorporates some of the memory model changes.)
>
> Daveed
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: addrspace attribute and intrisics

Torvald Riegel-3
In reply to this post by David Vandevoorde
There is also a PLDI 08 paper on this. The tech report version is at
http://www.hpl.hp.com/techreports/2008/HPL-2008-56.html

Torvald

On Tuesday 15 July 2008, David Vandevoorde wrote:

> If you're interested in the evolution of C++'s memory model, here are
> some papers on the topic:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html
>
> A working draft for the next C++ standard is also available:
>
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf
>
> (It incorporates some of the memory model changes.)
>
> Daveed
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev