similar to: [InstCombine] addrspacecast assumed associative with gep

> 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

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

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

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

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

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

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

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?

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

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

On 11 Sep 2017, at 21:32, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As a data point for this, I did a quick walkthrough of the top-level of instcombine, and one thing that stuck out to me is that it tries to sink instructions in certain "easy" scenarios. That doesn't fit a graph rewriting system. The sinking in instcombine is not always a win. We

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

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

Thanks, this makes the use case much more clear. Now though, as far as I would like actually to see supported in LLVM the capability of not having any special meaning assigned to address space 0 your proposal goes slightly in contrast with how I always thought of address spaces in LLVM. I also have to say that I don’t know deeply how address spaces are meant to be intended in LLVM so my vision of

Sanjoy Das wrote: > In your > example, foo will have to treat its argument differently depending on > whether it is a GC pointer or not. In practice, this is not true of many functions that don't call other functions. Take the example of a simple "print" function that takes a void * to cast and print, type_int to determine what to cast to: why should it care about whether