search for: p11i32

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....

...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....

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 spac...

...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 separ...

...omic 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 w...

...t; 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 lit...

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

...at 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 add...

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

...; > 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 n...

...at 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 add...

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

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