similar to: [LLVMdev] Pattern matching addrspacecast?

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

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

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

> 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

It appears that this behaviour of InstCombine is at least somewhat intended, as there are several tests that fail after the change mentioned before: cast.ll, gep-addrspace.ll and getelementptr.ll in test/Transforms/InstCombine. I feel a little uncomfortable applying the patch after knowing this, and removing those tests doesn't seem like a great solution. What are your thoughts? For now, I

On Tue, Mar 25, 2014 at 3:21 PM, Matt Arsenault <Matthew.Arsenault at amd.com>wrote: > On 03/25/2014 02:31 PM, Jingyue Wu wrote: > > > However, we have three concerns on this: > a) I doubt this optimization is valid for all targets, because LLVM > language reference ( > http://llvm.org/docs/LangRef.html#addrspacecast-to-instruction) says > addrspacecast "can be

On 16 Mar 2015, at 08:25, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > The LangRef says this about addrspacecast: "Note that if the address > space conversion is legal then both result and operand refer to the > same memory location.". This brings forth two related questions: > > 1. what happens if you execute an "invalid" addrspacecast?

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

Thank you for the prompt response, Matt. On Jan 20, 2014, at 3:03 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > Since 3.4 you need to use the addrspacecast instruction to cast between address spaces. It's possible there are still some places left that haven't been fixed yet to use it instead of creating bit casts. Are you saying you think this is a bug and it should

This is a follow-up discussion on http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140324/101899.html. The front-end change was already pushed in r204677, so we want to continue with the IR optimization. In general, we want to write an IR pass to convert generic address space usage to non-generic address space usage, because accessing the generic address space in CUDA and OpenCL is

Hi, I'd like to add support for addrspacecast in initializers of global variables, at least for the trivial case. The trivial case is if TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In this case the MCExpr for the addrspacecast is the MCExpr of its first operand. It seems hard to obtain an instance of TargetLowering in AsmPrinter::lowerConstant(). Other methods in

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

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

> On Dec 14, 2018, at 2:21 PM, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 12/11/18 6:51 PM, Doerfert, Johannes Rudolf via llvm-dev wrote: >> Hi, >> >> in a recent review [0], Florian Hahn helped me to realize something that >> was rather surprising to me: >> >> The widely popular and very useful function

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 Aug 10, 2013, at 6:07 , Iain Sandoe <iain at codesourcery.com> wrote: > >> RELATED PROBLEMS >> 1) addrspacecast support: approved but not implemented yet. It will >> cleanup address spaces conversions localized in a single instruction >> allowing each target to define the semantic... > > Is anyone known to be working on this? If people agree that this

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, I’ve recently encountered an issue where the `instcombine` pass replaces an `llvm.memcpy` between two distinct address spaces with an `addrspacecast` instruction. As an example, see the trivial OpenCL kernel attached. I’m compiling like this: clang -cc1 -triple spir64-unknown-unknown -x cl -O0 -emit-llvm array_init.cl -o before.ll This yields an `llvm.memcpy` to copy the array

Hello all .. my first post to this thread (and this list, as it happens).. On 10 Aug 2013, at 07:46, Michele Scandale wrote: > I just want make a quick summary: a summary is indeed useful. > OBJECTIVE: discuss for finding a way to represent logical (derived from > source language abstractions) address space also in the IR to be able to > exploit this information for optimizations.