search for: intrisically

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

Hi, On my out-of-tree target I have an intrinsic def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], [llvm_i16_ty, llvm_i16_ty], [IntrNoMem]>; that I want to translate to the following instruction during instruction selection: def divm16_pseudo : MyPseudoInst< (outs aNh_0_7:$dst, aNh_0_7:$dst2), (ins

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

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

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

> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On my out-of-tree target I have an intrinsic > > def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], > [llvm_i16_ty, llvm_i16_ty], > [IntrNoMem]>; > > that I want to translate to the

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

Hi, On 03/30/2016 11:38 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >> <mailto:mikael.holmen at ericsson.com>> wrote: >> >> i16 (divm16_pseudo …) >> >> stuff? >> >> I've tried >> (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) >> and >> ((i16, i16)

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

On 4 May 2015 at 08:37, Shahid, Asghar-ahmad <Asghar-ahmad.Shahid at amd.com> wrote: > My worry is regarding the query for cost calculation for 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,

Hi, On 03/30/2016 11:15 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On my out-of-tree target I have an intrinsic >> >> def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], >> [llvm_i16_ty, llvm_i16_ty], >>