search for: intrisic

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:

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

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,

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

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,

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

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

...1, src2): (divm16_pseudo:i16:i16:i16 ?:i16:$src1, ?:i16:$src2) error: In anonymous_1373: Type inference contradiction found, merging 'i16' into 'Any' def : Pat<(int_phx_divm_u16 i16:$src1, i16:$src2), ^ So is there a way I can get around this? Before ISel the call to my intrisic looks like %_tmp3 = call %rec6 @llvm.phx.divm.u16.rec6(i16 %_tmp1, i16 %_tmp2) and %rec6 is %rec6 = type { i16, i16 } Then at ISel, before selection the call is lowered to t6: i16,i16 = llvm.phx.divm.u16 TargetConstant:i16<3778>, t2, t4 which fits nicely to my divm16_pseudo tha...

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

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

...yed of topic for this list and so will stop now. Ben -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] 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...

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

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

...i16:$src1, ?:i16:$src2) > > error: In anonymous_1373: Type inference contradiction found, merging 'i16' into 'Any' > def : Pat<(int_phx_divm_u16 i16:$src1, i16:$src2), > ^ > > So is there a way I can get around this? > > > Before ISel the call to my intrisic looks like > > %_tmp3 = call %rec6 @llvm.phx.divm.u16.rec6(i16 %_tmp1, i16 %_tmp2) > > and %rec6 is > > %rec6 = type { i16, i16 } > > Then at ISel, before selection the call is lowered to > > t6: i16,i16 = llvm.phx.divm.u16 TargetConstant:i16<3778>, t2, t...

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

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

...; (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) >> and >> ((i16, i16) (divm16_pseudo i16:$src1, i16:$src2) >> and a few other variants without managing to get it through. >> >> Thanks again, >> Mikael > > Are you trying to return multiple values? Yes, the intrisic returns a record %rec6 = type { i16, i16 } so at instructions selection the original call %_tmp3 = call %rec6 @llvm.phx.divm.u16.rec6(i16 %_tmp1, i16 %_tmp2) has been lowered to t6: i16,i16 = llvm.phx.divm.u16 TargetConstant:i16<3778>, t2, t4 and the instruction I want to selec...

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

...specific SAD > instructions such as ‘psad’ (X86) or ‘usad’ (ARM) in Loop Vectorizer. Hi Shahid, The vectorizer's cost model has the ability to return different costs for the same instruction based on the arguments (scalar/vector, big/small, special cases), so I don't think that adding intrisics will help you in defining the correct cost. This is true for all other vectorizer's decisions and it works quite well. If you find something missing, maybe we should fix the cost model, not introduce more intrinsics. cheers, --renato

...>> error: In anonymous_1373: Type inference contradiction found, merging 'i16' into 'Any' >> def : Pat<(int_phx_divm_u16 i16:$src1, i16:$src2), >> ^ >> >> So is there a way I can get around this? >> >> >> Before ISel the call to my intrisic looks like >> >> %_tmp3 = call %rec6 @llvm.phx.divm.u16.rec6(i16 %_tmp1, i16 %_tmp2) >> >> and %rec6 is >> >> %rec6 = type { i16, i16 } >> >> Then at ISel, before selection the call is lowered to >> >> t6: i16,i16 = llvm.phx.divm.u16...