1 ; RUN: llc -march=r600 -mcpu=redwood -verify-machineinstrs < %s | FileCheck %s
3 ; This test checks that the lds input queue will is empty at the end of
6 ; CHECK-LABEL: {{^}}lds_input_queue:
7 ; CHECK: LDS_READ_RET * OQAP
8 ; CHECK-NOT: ALU clause
9 ; CHECK: MOV * T{{[0-9]\.[XYZW]}}, OQAP
11 @local_mem = internal unnamed_addr addrspace(3) global [2 x i32] undef, align 4
13 define amdgpu_kernel void @lds_input_queue(i32 addrspace(1)* %out, i32 addrspace(1)* %in, i32 %index) {
15 %0 = getelementptr inbounds [2 x i32], [2 x i32] addrspace(3)* @local_mem, i32 0, i32 %index
16 %1 = load i32, i32 addrspace(3)* %0
17 call void @llvm.r600.group.barrier()
19 ; This will start a new clause for the vertex fetch
20 %2 = load i32, i32 addrspace(1)* %in
22 store i32 %3, i32 addrspace(1)* %out
26 declare void @llvm.r600.group.barrier() nounwind convergent
28 ; The machine scheduler does not do proper alias analysis and assumes that
29 ; loads from global values (Note that a global value is different that a
30 ; value from global memory. A global value is a value that is declared
31 ; outside of a function, it can reside in any address space) alias with
34 ; This is a problem for scheduling the reads from the local data share (lds).
35 ; These reads are implemented using two instructions. The first copies the
36 ; data from lds into the lds output queue, and the second moves the data from
37 ; the input queue into main memory. These two instructions don't have to be
38 ; scheduled one after the other, but they do need to be scheduled in the same
39 ; clause. The aliasing problem mentioned above causes problems when there is a
40 ; load from global memory which immediately follows a load from a global value that
41 ; has been declared in the local memory space:
43 ; %0 = getelementptr inbounds [2 x i32], [2 x i32] addrspace(3)* @local_mem, i32 0, i32 %index
44 ; %1 = load i32, i32 addrspace(3)* %0
45 ; %2 = load i32, i32 addrspace(1)* %in
47 ; The instruction selection phase will generate ISA that looks like this:
48 ; %oqap = LDS_READ_RET
53 ; The bottom scheduler will schedule the two ALU instructions first:
56 ; %oqap = LDS_READ_RET
64 ; The lack of proper aliasing results in the local memory read (LDS_READ_RET)
65 ; to consider the global memory read (VTX_READ_32) has a chain dependency, so
66 ; the global memory read will always be scheduled first. This will give us a
67 ; final program which looks like this:
70 ; %oqap = LDS_READ_RET
77 ; This is an illegal program because the oqap def and use know occur in
78 ; different ALU clauses.
80 ; This test checks this scenario and makes sure it doesn't result in an
81 ; illegal program. For now, we have fixed this issue by merging the
82 ; LDS_READ_RET and MOV together during instruction selection and then
83 ; expanding them after scheduling. Once the scheduler has better alias
84 ; analysis, we should be able to keep these instructions sparate before
87 ; CHECK-LABEL: {{^}}local_global_alias:
89 ; CHECK-NOT: ALU clause
90 ; CHECK: MOV * T{{[0-9]\.[XYZW]}}, OQAP
91 define amdgpu_kernel void @local_global_alias(i32 addrspace(1)* %out, i32 addrspace(1)* %in) {
93 %0 = getelementptr inbounds [2 x i32], [2 x i32] addrspace(3)* @local_mem, i32 0, i32 0
94 %1 = load i32, i32 addrspace(3)* %0
95 %2 = load i32, i32 addrspace(1)* %in
97 store i32 %3, i32 addrspace(1)* %out