similar to: [LLVMdev] addrspace attribute and intrisics

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

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

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

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

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

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

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

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,

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

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:

I'm probably missing something simple here but in: CGDebugInfo.h: std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; but then in CGDebugInfo.cpp: llvm::DIType TC = getTypeOrNull(Ty); void * v = Ty.getAsOpaquePtr(); std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC); if (TC.Verify() && TC.isForwardDecl())

Hi Ben, Thanks that helped a lot. The problem seems to be that with the move to C++11 we now have: void std::vector<_Ty>::push_back(std::pair<_Ty1,_Ty2> &&)' and there no conversion operator that can be applied to convert: 'std::pair<_Ty1,_Ty2>' to 'std::pair<_Ty3,_Ty4> && Where: [ _Ty1=void *,

On 09.08.2012, at 19:43, "Gaster, Benedict" <Benedict.Gaster at amd.com> wrote: > I’m probably missing something simple here but in: > > CGDebugInfo.h: > > std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; > > but then in > > CGDebugInfo.cpp: > > llvm::DIType TC = getTypeOrNull(Ty); > > void * v =

The following code causes opt to not terminate! With TOT this morning, and of a week ago: clang foo.c and clang -O1 foo.c work fine. clang -O2 foo.c and clang -O3 foo.c do not terminate. (At least after 10 minutes) If I generate the bit code (clang-cc -emit-llvmbc) and then run: opt -O3 foo.bc it does not terminate. //foo.c int get_id(int); typedef short

We'd like to be able to vary the latency of our load instructions based on what address space is being loaded from. I was thinking I could do this by overriding getOperandLatency in our target, but I'm wondering if the addrspace info is available when instructions are scheduled? For example, I have this in our llvm IR: %0 = load i32 addrspace(4)* @answer, align 4 store i32 %0, i32*

Hi Eli, Yep I was being stupid. Please find attached a patch for initial changes to get MASM working. There is still one problem that I am looking into around changing alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256 alignments, default being 16, but LLVM is sometimes generating 32 alignment, for example, consider the following code: float bar(float fy, float fx) {