Files
clang-p2996/llvm/test/CodeGen/AMDGPU/amdpal.ll
Krzysztof Drewniak faa2c678aa [AMDGPU] Add buffer intrinsics that take resources as pointers
In order to enable the LLVM frontend to better analyze buffer
operations (and to potentially enable more precise analyses on the
backend), define versions of the raw and structured buffer intrinsics
that use `ptr addrspace(8)` instead of `<4 x i32>` to represent their
rsrc arguments.

The new intrinsics are named by replacing `buffer.` with `buffer.ptr`.

One advantage to these intrinsic definitions is that, instead of
specifying that a buffer load/store will read/write some memory, we
can indicate that the memory read or written will be based on the
pointer argument. This means that, for example, a read from a
`noalias` buffer can be pulled out of a loop that is modifying a
distinct buffer.

In the future, we will define custom PseudoSourceValues that will
allow us to package up the (buffer, index, offset) triples that buffer
intrinsics contain and allow for more precise backend analysis.

This work also enables creating address space 7, which represents
manipulation of raw buffers using native LLVM load and store
instructions.

Where tests simply used a buffer intrinsic while testing some other
code path (such as the tests for VGPR spills), they have been updated
to use the new intrinsic form. Tests that are "about" buffer
intrinsics (for instance, those that ensure that they codegen as
expected) have been duplicated, either within existing files or into
new ones.

Depends on D145441

Reviewed By: arsenm, #amdgpu

Differential Revision: https://reviews.llvm.org/D147547
2023-06-05 16:59:07 +00:00

93 lines
3.6 KiB
LLVM

; RUN: llc < %s -mtriple=amdgcn--amdpal -mcpu=tahiti | FileCheck --check-prefixes=PAL,CI --enable-var-scope %s
; RUN: llc < %s -mtriple=amdgcn--amdpal -mcpu=tonga | FileCheck --check-prefixes=PAL,VI --enable-var-scope %s
; PAL-NOT: .AMDGPU.config
; PAL-LABEL: {{^}}simple:
define amdgpu_kernel void @simple(ptr addrspace(1) %out) {
entry:
store i32 0, ptr addrspace(1) %out
ret void
}
; Check code sequence for amdpal use of scratch for alloca. This is the case
; where the high half of the address comes from s_getpc.
; PAL-LABEL: {{^}}scratch:
; PAL: s_getpc_b64 s[[[GITPTR:[0-9]+]]:
; PAL: s_mov_b32 s[[GITPTR]], s0
; PAL: s_load_dwordx4 s[[[SCRATCHDESC:[0-9]+]]:{{[0-9]+]}}, s[[[GITPTR]]:
; PAL: buffer_store{{.*}}, s[[[SCRATCHDESC]]:
define amdgpu_kernel void @scratch(<2 x i32> %in, i32 %idx, ptr addrspace(5) %out) {
entry:
%v = alloca [2 x i32], addrspace(5)
store <2 x i32> %in, ptr addrspace(5) %v
%e = getelementptr [2 x i32], ptr addrspace(5) %v, i32 0, i32 %idx
%x = load i32, ptr addrspace(5) %e
store i32 %x, ptr addrspace(5) %out
ret void
}
; Check code sequence for amdpal use of scratch for alloca. This is the case
; where the amdgpu-git-ptr-high function attribute gives the high half of the
; address to use.
; Looks like you can't do arithmetic on a filecheck variable, so we can't test
; that the s_movk_i32 is into a reg that is one more than the following
; s_mov_b32.
; PAL-LABEL: {{^}}scratch2:
; PAL: s_movk_i32 s{{[0-9]+}}, 0x1234
; PAL: s_mov_b32 s[[GITPTR:[0-9]+]], s0
; PAL: s_load_dwordx4 s[[[SCRATCHDESC:[0-9]+]]:{{[0-9]+]}}, s[[[GITPTR]]:
; PAL: buffer_store{{.*}}, s[[[SCRATCHDESC]]:
define amdgpu_kernel void @scratch2(<2 x i32> %in, i32 %idx, ptr addrspace(5) %out) #0 {
entry:
%v = alloca [2 x i32], addrspace(5)
store <2 x i32> %in, ptr addrspace(5) %v
%e = getelementptr [2 x i32], ptr addrspace(5) %v, i32 0, i32 %idx
%x = load i32, ptr addrspace(5) %e
store i32 %x, ptr addrspace(5) %out
ret void
}
; Check code sequence for amdpal use of scratch for alloca in a compute shader.
; The scratch descriptor is loaded from offset 0x10 of the GIT, rather than offset
; 0 in a graphics shader.
; Prior to GCN3 s_load_dword offsets are dwords, so the offset will be 0x4.
; PAL-LABEL: {{^}}scratch2_cs:
; PAL: s_movk_i32 s{{[0-9]+}}, 0x1234
; PAL: s_mov_b32 s[[GITPTR:[0-9]+]], s0
; CI: s_load_dwordx4 s[[[SCRATCHDESC:[0-9]+]]:{{[0-9]+]}}, s[[[GITPTR]]:{{[0-9]+\]}}, 0x4
; VI: s_load_dwordx4 s[[[SCRATCHDESC:[0-9]+]]:{{[0-9]+]}}, s[[[GITPTR]]:{{[0-9]+\]}}, 0x10
; PAL: buffer_store{{.*}}, s[[[SCRATCHDESC]]:
define amdgpu_cs void @scratch2_cs(i32 inreg, i32 inreg, i32 inreg, <3 x i32> inreg, i32 inreg, <3 x i32> %coord, <2 x i32> %in, i32 %extra, i32 %idx) #0 {
entry:
%v = alloca [3 x i32], addrspace(5)
%v1 = getelementptr [3 x i32], ptr addrspace(5) %v, i32 0, i32 1
store i32 %extra, ptr addrspace(5) %v
store <2 x i32> %in, ptr addrspace(5) %v1
%e = getelementptr [2 x i32], ptr addrspace(5) %v1, i32 0, i32 %idx
%x = load i32, ptr addrspace(5) %e
%xf = bitcast i32 %x to float
call void @llvm.amdgcn.raw.ptr.buffer.store.f32(float %xf, ptr addrspace(8) undef, i32 0, i32 0, i32 0)
ret void
}
attributes #0 = { nounwind "amdgpu-git-ptr-high"="0x1234" }
declare void @llvm.amdgcn.raw.ptr.buffer.store.f32(float, ptr addrspace(8), i32, i32, i32 immarg)
; PAL: .amdgpu_pal_metadata
; PAL-NEXT: ---
; PAL-NEXT: amdpal.pipelines:
; PAL-NEXT: - .hardware_stages:
; PAL-NEXT: .cs:
; PAL-NEXT: .entry_point: scratch2_cs
; PAL-NEXT: .scratch_memory_size: 0x10
; PAL-NEXT: .sgpr_count: 0x
; PAL-NEXT: .vgpr_count: 0x