search for: addrspacecasts

Given a pointer, does any addrspacecast affect the pointer's dereferenceablity ? For example, %pm = addrspaacecast float addrspacecast(n)* %pn to float addrspacecast(m)* %r = load float addrspace(m)* %pm In another word. the question is whether the following is true ? isDereferenceablePointer(pn) == isDereferenceablePointer(pm) [Note that the function is defined as

...d. Therefore, I would vote for making this optimization NVPTX-specific for now. If other targets need this, we can later think about how to reuse the code. 2. How effective do we want this optimization to be? In the short term, I want it to be able to eliminate unnecessary non-generic-to-generic addrspacecasts the front-end generates for the NVPTX target. For example, %p1 = addrspace i32 addrspace(3)* %p0 to i32* %v = load i32* %p1 => %v = load i32 addrspace(3)* %p0 We want similar optimization for store+addrspacecast and gep+addrspacecast as well. In a long term, we could for sure improve this o...

...generic address space. There's no special machine instruction to read/write from/to the generic address space in R600? > > > 2. How effective do we want this optimization to be? > > In the short term, I want it to be able to eliminate unnecessary > non-generic-to-generic addrspacecasts the front-end generates for the NVPTX > target. For example, > > %p1 = addrspace i32 addrspace(3)* %p0 to i32* > %v = load i32* %p1 > > => > > %v = load i32 addrspace(3)* %p0 > > We want similar optimization for store+addrspacecast and > gep+addrspacecast as...

Hi all, the addrspacecast stuff has landed and I'm now seeing failures in our back end because clang is emitting them, they're travelling through the IR to the SelectionDAG, and there's nothing to match them. Trying to match them, I get an error from TableGen saying: Variable not defined: 'addrspacecast' If I try to set a custom OperationAction in the target lowering class

...won't work. My impression is that this is not possible because every function has its own TargetLowering instance. Is that correct? NVPTX solves the problem by having a method on it's NVPTXAsmPrinter class, which is mostly a copy of AsmPrinter::lowerConstant() and knows how to handle addrspacecasts. However, this probably isn't a solution for e.g. X86. Suggestions are highly welcome. -Manuel

From: Villmow, Micah Sent: Tuesday, September 11, 2012 12:51 PM To: llvm-commits at cs.uiuc.edu Subject: Proposal: New IR instruction for casting between address spaces Problem: Bit casting between pointers of different address spaces only works if all address space pointers are the same size. With changes from email chain [1][2], support for different pointer sizes breaks the bitcast instruction

...to the > same memory location.". This brings forth two related questions: > > 1. what happens if you execute an "invalid" addrspacecast? Does this > axiom make addrspacecast non-hoistable? From a quick glance at > the code, ValueTracking seems to assume that addrspacecasts can be > speculatively executed. > > 2. even if two pointers from two different address spaces point to > the same "location", can one of them not be dereferenceable while > the other is? In other words, does dereferenceability depend on > the addrspace of...

On 17 Mar 2015, at 20:06, Junjie Gu <jgu222 at gmail.com> wrote: >> I've just been debugging a related issue with regard to commutativity of address space casts with respect to other operations. One of the optimisers is turning an add after an address space cast into an add before the address space cast. On our architecture, this results in different bounds information being

The following combine(-enabling transformation) makes me uncomfortable:   gep(addrspacecast(gep p0) to p1)   addrspacecast(gep(gep p0)) to p1 It's applied at visitAddrSpaceCast in InstCombineCasts.cpp. Before this, I'd always assumed address spaces were very much "user domain". Datalayout even supports marking a space as "non-integral", to designate that manipulation as

OK, I’ve hit one more existing regression test that I’m weary of: define void @test2_addrspacecast() { %A = alloca %T %B = alloca %T %a = addrspacecast %T* %A to i8 addrspace(1)* %b = addrspacecast %T* %B to i8 addrspace(1)* call void @llvm.memcpy.p1i8.p0i8.i64(i8 addrspace(1)* %a, i8* bitcast (%T* @G to i8*), i64 124, i32 4, i1 false) call void

On Sep 11, 2012, at 1:03 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > From: Villmow, Micah > Sent: Tuesday, September 11, 2012 12:51 PM > To: llvm-commits at cs.uiuc.edu > Subject: Proposal: New IR instruction for casting between address spaces > > Problem: > Bit casting between pointers of different address spaces only works if all

> -----Original Message----- > From: Dan Gohman [mailto:gohman at apple.com] > Sent: Tuesday, September 11, 2012 1:28 PM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > On Sep 11, 2012, at 1:03 PM, "Villmow, Micah" <Micah.Villmow at amd.com> > wrote: >

> What do you mean exactly by "behave differently on the other side of the cast”? Do you have a concrete example? I was hesitant to say only in that it is probably an "abuse of mechanics" and definitely playing with fire, _however_ the target I'm working on has extensive bit operations for a subset of memory, including atomic test-and-set, etc. It's convenient to be

Hi Mehdi, Thanks for the reply - I’ve finally got round to trying to fix this based on your suggestion. I’ve got something that mostly works, but I just wanted to double-check something about the regression tests before I post a patch. > The memcpy is supposed to be equivalent to a sequence of load and store. Here we are just failing to keep the property that the load is performed through

Hi all! On x86_64, segment prefix fs: is in address space 257 and gs: in address space 256. (BTW: are there constants for these magic values?) How can I use this in IR? I want to express this assembler code in IR: mov RAX, 8; mov RAX, GS:[RAX]; ret; I tried the following: define i64 @getStackBottom(i64 %addr) { entry: %ptr = inttoptr

In the following example, for some reasons, the input pointer entering the loop was casted to generic pointer. How can the backend get rid of the addrspacecast and use local store in the loop? for.body.lr.ph: ; preds = %entry %0 = addrspacecast i32 addrspace(3)* %in to i32 addrspace(4)* br label %for.body for.body: ; preds = %for.body, %for.body.lr.ph %i.03 = phi i32 [ 0, %for.body.lr.ph ],

On 2 Sep 2015, at 02:54, Joseph Tremoulet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Reading further, I see both that addrspacecast "can be a no-op cast or a complex value modification"[2] and that bitcast "may only be [used on pointers] with the same address space"[4]. > > So I'm getting the impression that it's ok to have a model with

I was reading the LangRef for semantics of an instruction and came across addrspacecast. I've never needed it, so I suppose I don't care about it. But, why does it exist? What problem is it trying to solve?

Hi, On Sep 11, 2012, at 2:30 PM, Villmow, Micah wrote: > > >> -----Original Message----- >> From: Dan Gohman [mailto:gohman at apple.com] >> Sent: Tuesday, September 11, 2012 1:28 PM >> To: Villmow, Micah >> Cc: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between >> address spaces >> >>

> -----Original Message----- > From: Mon P Wang [mailto:monping at apple.com] > Sent: Wednesday, September 12, 2012 1:12 PM > To: Villmow, Micah > Cc: Dan Gohman; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > Hi, > > On Sep 11, 2012, at 2:30 PM, Villmow, Micah wrote: > > > > >