search for: addrspace

Is copy.0 semantically equivalent to copy.1 in the following example? define void @copy.0(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst) { entry: %val = load i8 addrspace(1)* addrspace(1)* %src store i8 addrspace(1)* %val, i8 addrspace(1)* addrspace(1)* %dst ret void } define void @copy.1(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst) {...

...5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > > In other words, assuming pointers have the same size irrespective of > address spaces, is storing / loading an (not storing into / loading > from) addrspace(1)* allowed to do something semantically different > than storing...

...@vector_add.async_buffer = internal addrspace(2) global [4 x double] undef, align 8...

Hello, LLVM devs. I have the following IR: %x = alloca i32, align 4 %p = alloca i32*, align 8 store i32* %x, i32** %p, align 8 Now I change module's data layout and run InferAddressSpacePass. This turns that piece of code into %x = alloca i32, align 4, addrspace(1) %p = alloca i32*, align 8, addrspace(1) store i32 addrspace(1)* %x, i32* addrspace(1)* %p, align 8 But Verifier complains that the module is invalid, saying error: stored value and pointer type do not match store i32 addrspace(1)* %x3, i32* addrspace(1)* %p4, align 8 I didn't even man...

...> -;SI-CHECK: V_ADD_I32_e32 [[REG:v[0-9]+]], {{v[0-9]+, v[0-9]+}} > -;SI-CHECK-NOT: [[REG]] > -;SI-CHECK: BUFFER_STORE_DWORD [[REG]], > +;SI: V_ADD_I32_e32 [[REG:v[0-9]+]], {{v[0-9]+, v[0-9]+}} > +;SI-NOT: [[REG]] > +;SI: BUFFER_STORE_DWORD [[REG]], > define void @test1(i32 addrspace(1)* %out, i32 addrspace(1)* %in) { > %b_ptr = getelementptr i32 addrspace(1)* %in, i32 1 > %a = load i32 addrspace(1)* %in > @@ -17,11 +17,11 @@ define void @test1(i32 addrspace(1)* %out, i32 addrspace(1)* %in) { > } > > ;FUNC-LABEL: @test2: > -;EG-CHECK: ADD_INT {{[*...

Hello, With the following reduced test case, cmd "opt -always-inline t.ll" crashes after inlining. Notice that byval argument %a will be remapped to %1 below, and consequently produces an illegal store. %1 = alloca i32, align 4 store i32 * %1, i32 addrspace(1)** %a.addr, align 8 Looks like Inliner assumes that byval arguments are from address space 0. Or this is just a bug in inliner? Thanks, Wei t.ll: define i32 @foo(i32 addrspace(1)* %x) { entry: %y = call i32 @bar(i32 addrspace(1)* %x) ret i32 %y } define internal i32 @bar(i32 addrspace(1)...

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* @xint, align 4 %1 = load i32 addrspace(2)* @seven, align 4 store i32 %1, i32* %bint, align 4 %2 = load i32 addrspace(3)* @two, alig...

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 @llvm.memc...

I am attempting to get indexing code generation working with my backend. However, it seems that the addresses being calculated is being multiplied by the width of the data type. define void @ test_input_index_constant_int(i32 addrspace(11)* %input, i32 addrspace(11)* %result) { entry: %input.addr = alloca i32 addrspace(11)* ; <i32 addrspace(11)**> [#uses=2] %result.addr = alloca i32 addrspace(11)* ; <i32 addrspace(11)**> [#uses=2] store i32 addrspace(11)* %input, i32...

...estion. 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 addrspace(2). Based on this comment, I am suspicious of the validity of a couple of existing instcombine regression tests in `memcpy-from-global.ll`. Specifically, there are two tests that look like this: define void @test3_addrspacecast() { %A = alloca %T %a = bitcast %T* %A to i8* call voi...

It is problematic when byval argument is not from address space 0. When the default alloca address space is 0, should we consider this IR illegal? define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline From: Reid Kleckner [mailto:rnk at google.com] Sent: Tuesday, September 25, 2018 2:38 PM To: Pan, Wei <wei.pan at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] byval argument causes llvm to crash after inlining Well, they are...

...cs.ll > @@ -758,6 +758,95 @@ entry: > ret void > } > > +; CMP_SWAP > + > +; FUNC-LABEL: {{^}}atomic_cmpxchg_i32_offset: > +; GCN: buffer_atomic_cmpswap v[{{[0-9]+}}:{{[0-9]+}}], s[{{[0-9]+}}:{{[0-9]+}}], 0 offset:16{{$}} > +define void @atomic_cmpxchg_i32_offset(i32 addrspace(1)* %out, i32 %in, i32 %old) { > +entry: > + %gep = getelementptr i32, i32 addrspace(1)* %out, i32 4 > + %0 = cmpxchg volatile i32 addrspace(1)* %gep, i32 %old, i32 %in seq_cst seq_cst > + ret void > +} > + > +; FUNC-LABEL: {{^}}atomic_cmpxchg_i32_ret_offset: > +; GCN: b...

It's not clear what is actually wrong from your original message, I think you need to give some more information as to what you are doing: Example source, what target GPU, compiler error messages or other evidence of "it's wrong" (llvm IR, disassembly, etc) ... -- Mats On 8 April 2016 at 09:55, Liu Xin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I built it

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

Hello, Calling `replaceUsesOfWith` with a value in a different addrspace does not keep the addrspace of a GEP consistent. Is this known? Is this a bug or expected behaviour? Minimal counterexample link <https://gist.github.com/bollu/152ba5e1c20c03c7fc6d8c7b23ba828f> Reproduced here: #include <iostream> #include "llvm/ADT/APFloat.h" #include &quo...

...tack, so it has to be in the same address space. -Eli On 9/25/2018 3:00 PM, Pan, Wei via llvm-dev wrote: > It is problematic when byval argument is not from address space 0. When the default alloca address space is 0, should we consider this IR illegal? > > define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline > > > From: Reid Kleckner [mailto:rnk at google.com] > Sent: Tuesday, September 25, 2018 2:38 PM > To: Pan, Wei <wei.pan at intel.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] byval argument causes llvm to cras...

...lt of a function call is a deopt arg to llvm.experimental.gc.statepoint (http://llvm.org/docs/Statepoints.html#llvm-experimental-gc-statepoint-intrinsic). Therefore a Stack Map containing location of this variable is created upon code generation. Here's the complete example: define i64 addrspace(1)* @func() { %p = inttoptr i64 42 to i64 addrspace(1)* ret i64 addrspace(1)* %p } define i8 @main() #0 gc "statepoint-example" { %result = call i64 addrspace(1)* @func() %token = call i32 (i64, i32, i64 addrspace(1)* ()*, i32, i32, ...) @l...

...talayout = "e-p:32:32:32" ; Function Attrs: noduplicate nounwind declare void @__amdil_barrier_local() #0 ; Function Attrs: nounwind readnone declare <4 x i32> @__amdil_get_local_id_int() #1 ; Function Attrs: nounwind define void @__OpenCL_execFFT_reduced_kernel(<2 x float> addrspace(1)* noalias nocapture %in, <2 x float> addrspace(1)* noalias nocapture %out, <2 x float> addrspace(3)* nocapture %data0) #2 { entry: %0 = tail call <4 x i32> @__amdil_get_local_id_int() #2 %1 = extractelement <4 x i32> %0, i32 0 %arrayidx = getelementptr <2 x float&...

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) == isDereferenceabl...

...MP0x, TEMP0x, 0 RET ENDSUB and add.ll has: ;FUNC-LABEL: {{^}}test1: ;EG: ADD_INT {{[* ]*}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}} ;SI: v_add_i32_e32 [[REG:v[0-9]+]], vcc, {{v[0-9]+, v[0-9]+}} ;SI-NOT: [[REG]] ;SI: buffer_store_dword [[REG]], define void @test1(i32 addrspace(1)* %out, i32 addrspace(1)* %in) { %b_ptr = getelementptr i32, i32 addrspace(1)* %in, i32 1 %a = load i32, i32 addrspace(1)* %in %b = load i32, i32 addrspace(1)* %b_ptr %result = add i32 %a, %b store i32 %result, i32 addrspace(1)* %out ret void } So the generated code for test1 r...