2019-05-22 05:49:14 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
|
|
|
; RUN: llc -march=amdgcn -verify-machineinstrs < %s | FileCheck --check-prefixes=GCN,GFX8,VARIANT0 %s
|
|
|
|
|
; RUN: llc -march=amdgcn -mattr=+auto-waitcnt-before-barrier -verify-machineinstrs < %s | FileCheck --check-prefixes=GCN,GFX8,VARIANT1 %s
|
|
|
|
|
; RUN: llc -march=amdgcn -mcpu=gfx900 -verify-machineinstrs < %s | FileCheck --check-prefixes=GCN,GFX9,VARIANT2 %s
|
|
|
|
|
; RUN: llc -march=amdgcn -mcpu=gfx900 -mattr=+auto-waitcnt-before-barrier -verify-machineinstrs < %s | FileCheck --check-prefixes=GCN,GFX9,VARIANT3 %s
|
2016-01-23 05:30:43 +08:00
|
|
|
|
2017-05-18 05:38:21 +08:00
|
|
|
define amdgpu_kernel void @test_barrier(i32 addrspace(1)* %out, i32 %size) #0 {
|
2019-05-22 05:49:14 +08:00
|
|
|
; VARIANT0-LABEL: test_barrier:
|
|
|
|
|
; VARIANT0: ; %bb.0: ; %entry
|
|
|
|
|
; VARIANT0-NEXT: s_load_dwordx2 s[4:5], s[0:1], 0x9
|
|
|
|
|
; VARIANT0-NEXT: s_load_dword s2, s[0:1], 0xb
|
|
|
|
|
; VARIANT0-NEXT: s_mov_b32 s7, 0xf000
|
|
|
|
|
; VARIANT0-NEXT: s_mov_b32 s6, 0
|
|
|
|
|
; VARIANT0-NEXT: v_lshlrev_b32_e32 v1, 2, v0
|
|
|
|
|
; VARIANT0-NEXT: v_mov_b32_e32 v2, 0
|
|
|
|
|
; VARIANT0-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
|
; VARIANT0-NEXT: buffer_store_dword v0, v[1:2], s[4:7], 0 addr64
|
[DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C fold. Try 3
Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.
AArch64 test changes all look good (`neg` created), or neutral.
X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).
I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.
I'm unable to interpret AMDGPU change, looks neutral-ish?
This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].
https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: craig.topper, RKSimon, spatel, arsenm
Reviewed By: RKSimon
Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62223
llvm-svn: 362142
2019-05-31 04:36:54 +08:00
|
|
|
; VARIANT0-NEXT: s_waitcnt expcnt(0)
|
|
|
|
|
; VARIANT0-NEXT: v_sub_i32_e32 v0, vcc, s2, v0
|
|
|
|
|
; VARIANT0-NEXT: s_waitcnt vmcnt(0)
|
2019-05-22 05:49:14 +08:00
|
|
|
; VARIANT0-NEXT: s_barrier
|
[DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C fold. Try 3
Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.
AArch64 test changes all look good (`neg` created), or neutral.
X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).
I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.
I'm unable to interpret AMDGPU change, looks neutral-ish?
This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].
https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: craig.topper, RKSimon, spatel, arsenm
Reviewed By: RKSimon
Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62223
llvm-svn: 362142
2019-05-31 04:36:54 +08:00
|
|
|
; VARIANT0-NEXT: v_add_i32_e32 v3, vcc, -1, v0
|
2019-05-22 05:49:14 +08:00
|
|
|
; VARIANT0-NEXT: v_ashrrev_i32_e32 v4, 31, v3
|
|
|
|
|
; VARIANT0-NEXT: v_lshl_b64 v[3:4], v[3:4], 2
|
|
|
|
|
; VARIANT0-NEXT: buffer_load_dword v0, v[3:4], s[4:7], 0 addr64
|
|
|
|
|
; VARIANT0-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
|
; VARIANT0-NEXT: buffer_store_dword v0, v[1:2], s[4:7], 0 addr64
|
|
|
|
|
; VARIANT0-NEXT: s_endpgm
|
|
|
|
|
;
|
|
|
|
|
; VARIANT1-LABEL: test_barrier:
|
|
|
|
|
; VARIANT1: ; %bb.0: ; %entry
|
|
|
|
|
; VARIANT1-NEXT: s_load_dwordx2 s[4:5], s[0:1], 0x9
|
|
|
|
|
; VARIANT1-NEXT: s_load_dword s2, s[0:1], 0xb
|
|
|
|
|
; VARIANT1-NEXT: s_mov_b32 s7, 0xf000
|
|
|
|
|
; VARIANT1-NEXT: s_mov_b32 s6, 0
|
|
|
|
|
; VARIANT1-NEXT: v_lshlrev_b32_e32 v1, 2, v0
|
|
|
|
|
; VARIANT1-NEXT: v_mov_b32_e32 v2, 0
|
|
|
|
|
; VARIANT1-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
|
; VARIANT1-NEXT: buffer_store_dword v0, v[1:2], s[4:7], 0 addr64
|
[DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C fold. Try 3
Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.
AArch64 test changes all look good (`neg` created), or neutral.
X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).
I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.
I'm unable to interpret AMDGPU change, looks neutral-ish?
This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].
https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: craig.topper, RKSimon, spatel, arsenm
Reviewed By: RKSimon
Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62223
llvm-svn: 362142
2019-05-31 04:36:54 +08:00
|
|
|
; VARIANT1-NEXT: s_waitcnt expcnt(0)
|
|
|
|
|
; VARIANT1-NEXT: v_sub_i32_e32 v0, vcc, s2, v0
|
2019-05-22 05:49:14 +08:00
|
|
|
; VARIANT1-NEXT: s_barrier
|
[DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C fold. Try 3
Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.
AArch64 test changes all look good (`neg` created), or neutral.
X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).
I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.
I'm unable to interpret AMDGPU change, looks neutral-ish?
This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].
https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: craig.topper, RKSimon, spatel, arsenm
Reviewed By: RKSimon
Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62223
llvm-svn: 362142
2019-05-31 04:36:54 +08:00
|
|
|
; VARIANT1-NEXT: v_add_i32_e32 v3, vcc, -1, v0
|
2019-05-22 05:49:14 +08:00
|
|
|
; VARIANT1-NEXT: v_ashrrev_i32_e32 v4, 31, v3
|
|
|
|
|
; VARIANT1-NEXT: v_lshl_b64 v[3:4], v[3:4], 2
|
|
|
|
|
; VARIANT1-NEXT: buffer_load_dword v0, v[3:4], s[4:7], 0 addr64
|
|
|
|
|
; VARIANT1-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
|
; VARIANT1-NEXT: buffer_store_dword v0, v[1:2], s[4:7], 0 addr64
|
|
|
|
|
; VARIANT1-NEXT: s_endpgm
|
|
|
|
|
;
|
|
|
|
|
; VARIANT2-LABEL: test_barrier:
|
|
|
|
|
; VARIANT2: ; %bb.0: ; %entry
|
|
|
|
|
; VARIANT2-NEXT: s_load_dwordx2 s[2:3], s[0:1], 0x24
|
|
|
|
|
; VARIANT2-NEXT: v_lshlrev_b32_e32 v1, 2, v0
|
|
|
|
|
; VARIANT2-NEXT: s_load_dword s0, s[0:1], 0x2c
|
|
|
|
|
; VARIANT2-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
|
; VARIANT2-NEXT: v_mov_b32_e32 v2, s3
|
|
|
|
|
; VARIANT2-NEXT: v_add_co_u32_e32 v1, vcc, s2, v1
|
|
|
|
|
; VARIANT2-NEXT: v_addc_co_u32_e32 v2, vcc, 0, v2, vcc
|
|
|
|
|
; VARIANT2-NEXT: global_store_dword v[1:2], v0, off
|
|
|
|
|
; VARIANT2-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
|
; VARIANT2-NEXT: s_barrier
|
[DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C fold. Try 3
Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.
AArch64 test changes all look good (`neg` created), or neutral.
X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).
I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.
I'm unable to interpret AMDGPU change, looks neutral-ish?
This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].
https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: craig.topper, RKSimon, spatel, arsenm
Reviewed By: RKSimon
Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62223
llvm-svn: 362142
2019-05-31 04:36:54 +08:00
|
|
|
; VARIANT2-NEXT: v_sub_u32_e32 v0, s0, v0
|
|
|
|
|
; VARIANT2-NEXT: v_add_u32_e32 v3, -1, v0
|
2019-05-22 05:49:14 +08:00
|
|
|
; VARIANT2-NEXT: v_ashrrev_i32_e32 v4, 31, v3
|
|
|
|
|
; VARIANT2-NEXT: v_lshlrev_b64 v[3:4], 2, v[3:4]
|
|
|
|
|
; VARIANT2-NEXT: v_mov_b32_e32 v0, s3
|
|
|
|
|
; VARIANT2-NEXT: v_add_co_u32_e32 v3, vcc, s2, v3
|
|
|
|
|
; VARIANT2-NEXT: v_addc_co_u32_e32 v4, vcc, v0, v4, vcc
|
|
|
|
|
; VARIANT2-NEXT: global_load_dword v0, v[3:4], off
|
|
|
|
|
; VARIANT2-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
|
; VARIANT2-NEXT: global_store_dword v[1:2], v0, off
|
|
|
|
|
; VARIANT2-NEXT: s_endpgm
|
|
|
|
|
;
|
|
|
|
|
; VARIANT3-LABEL: test_barrier:
|
|
|
|
|
; VARIANT3: ; %bb.0: ; %entry
|
|
|
|
|
; VARIANT3-NEXT: s_load_dwordx2 s[2:3], s[0:1], 0x24
|
|
|
|
|
; VARIANT3-NEXT: v_lshlrev_b32_e32 v1, 2, v0
|
|
|
|
|
; VARIANT3-NEXT: s_load_dword s0, s[0:1], 0x2c
|
|
|
|
|
; VARIANT3-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
|
; VARIANT3-NEXT: v_mov_b32_e32 v2, s3
|
|
|
|
|
; VARIANT3-NEXT: v_add_co_u32_e32 v1, vcc, s2, v1
|
|
|
|
|
; VARIANT3-NEXT: v_addc_co_u32_e32 v2, vcc, 0, v2, vcc
|
|
|
|
|
; VARIANT3-NEXT: global_store_dword v[1:2], v0, off
|
|
|
|
|
; VARIANT3-NEXT: s_barrier
|
[DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C fold. Try 3
Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.
AArch64 test changes all look good (`neg` created), or neutral.
X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).
I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.
I'm unable to interpret AMDGPU change, looks neutral-ish?
This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].
https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: craig.topper, RKSimon, spatel, arsenm
Reviewed By: RKSimon
Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62223
llvm-svn: 362142
2019-05-31 04:36:54 +08:00
|
|
|
; VARIANT3-NEXT: v_sub_u32_e32 v0, s0, v0
|
|
|
|
|
; VARIANT3-NEXT: v_add_u32_e32 v3, -1, v0
|
2019-05-22 05:49:14 +08:00
|
|
|
; VARIANT3-NEXT: v_ashrrev_i32_e32 v4, 31, v3
|
|
|
|
|
; VARIANT3-NEXT: v_lshlrev_b64 v[3:4], 2, v[3:4]
|
|
|
|
|
; VARIANT3-NEXT: v_mov_b32_e32 v0, s3
|
|
|
|
|
; VARIANT3-NEXT: v_add_co_u32_e32 v3, vcc, s2, v3
|
|
|
|
|
; VARIANT3-NEXT: v_addc_co_u32_e32 v4, vcc, v0, v4, vcc
|
|
|
|
|
; VARIANT3-NEXT: global_load_dword v0, v[3:4], off
|
|
|
|
|
; VARIANT3-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
|
; VARIANT3-NEXT: global_store_dword v[1:2], v0, off
|
|
|
|
|
; VARIANT3-NEXT: s_endpgm
|
2016-01-23 05:30:43 +08:00
|
|
|
entry:
|
2016-02-11 14:02:01 +08:00
|
|
|
%tmp = call i32 @llvm.amdgcn.workitem.id.x()
|
2016-01-23 05:30:43 +08:00
|
|
|
%tmp1 = getelementptr i32, i32 addrspace(1)* %out, i32 %tmp
|
|
|
|
|
store i32 %tmp, i32 addrspace(1)* %tmp1
|
|
|
|
|
call void @llvm.amdgcn.s.barrier()
|
2017-05-18 05:38:21 +08:00
|
|
|
%tmp3 = sub i32 %size, 1
|
2016-01-23 05:30:43 +08:00
|
|
|
%tmp4 = sub i32 %tmp3, %tmp
|
|
|
|
|
%tmp5 = getelementptr i32, i32 addrspace(1)* %out, i32 %tmp4
|
|
|
|
|
%tmp6 = load i32, i32 addrspace(1)* %tmp5
|
|
|
|
|
store i32 %tmp6, i32 addrspace(1)* %tmp1
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
declare void @llvm.amdgcn.s.barrier() #1
|
2016-02-11 14:02:01 +08:00
|
|
|
declare i32 @llvm.amdgcn.workitem.id.x() #2
|
2016-01-23 05:30:43 +08:00
|
|
|
|
|
|
|
|
attributes #0 = { nounwind }
|
|
|
|
|
attributes #1 = { convergent nounwind }
|
|
|
|
|
attributes #2 = { nounwind readnone }
|