maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/AMDGPU/amdgpu-codegenprepare-fold-...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

514 lines
21 KiB
LLVM
Raw Normal View History

[AMDGPU] Remove dubious logic in bidirectional list scheduler Summary: pickNodeBidirectional tried to compare the best top candidate and the best bottom candidate by examining TopCand.Reason and BotCand.Reason. This is unsound because, after calling pickNodeFromQueue, Cand.Reason does not reflect the most important reason why Cand was chosen. Rather it reflects the most recent reason why it beat some other potential candidate, which could have been for some low priority tie breaker reason. I have seen this cause problems where TopCand is a good candidate, but because TopCand.Reason is ORDER (which is very low priority) it is repeatedly ignored in favour of a mediocre BotCand. This is not how bidirectional scheduling is supposed to work. To fix this I changed the code to always compare TopCand and BotCand directly, like the generic implementation of pickNodeBidirectional does. This removes some uncommented AMDGPU-specific logic; if this logic turns out to be important then perhaps it could be moved into an override of tryCandidate instead. Graphics shader benchmarking on gfx10 shows a lot more positive than negative effects from this change. Reviewers: arsenm, tstellar, rampitec, kzhuravl, vpykhtin, dstuttard, tpr, atrick, MatzeB Subscribers: jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68338
2019-10-07 22:33:59 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; RUN: opt -S -mtriple=amdgcn-amd-amdhsa -mcpu=fiji -amdgpu-codegenprepare %s | FileCheck -check-prefix=IR %s
; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=fiji < %s | FileCheck -check-prefix=GCN %s
define i32 @select_sdiv_lhs_const_i32(i1 %cond) {
; IR-LABEL: @select_sdiv_lhs_const_i32(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 200000, i32 125000
; IR-NEXT: ret i32 [[OP]]
;
; GCN-LABEL: select_sdiv_lhs_const_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x1e848
; GCN-NEXT: v_mov_b32_e32 v2, 0x30d40
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i32 5, i32 8
%op = sdiv i32 1000000, %select
ret i32 %op
}
define i32 @select_sdiv_rhs_const_i32(i1 %cond) {
; IR-LABEL: @select_sdiv_rhs_const_i32(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 1000, i32 10000
; IR-NEXT: ret i32 [[OP]]
;
; GCN-LABEL: select_sdiv_rhs_const_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x2710
; GCN-NEXT: v_mov_b32_e32 v2, 0x3e8
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i32 42000, i32 420000
%op = sdiv i32 %select, 42
ret i32 %op
}
define <2 x i32> @select_sdiv_lhs_const_v2i32(i1 %cond) {
; IR-LABEL: @select_sdiv_lhs_const_v2i32(
Revert "[ConstantFold] Fold more operations to poison" This reverts commit 53040a968dc2ff20931661e55f05da2ef8b964a0 due to its bad interaction with select i1 -> and/or i1 transformation. This fixes: https://bugs.llvm.org/show_bug.cgi?id=49005 https://bugs.llvm.org/show_bug.cgi?id=48435
2021-02-03 23:07:04 +08:00
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], <2 x i32> <i32 666, i32 undef>, <2 x i32> <i32 555, i32 1428>
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; IR-NEXT: ret <2 x i32> [[OP]]
;
; GCN-LABEL: select_sdiv_lhs_const_v2i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x22b
; GCN-NEXT: v_mov_b32_e32 v2, 0x29a
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: v_mov_b32_e32 v1, 0x594
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, <2 x i32> <i32 5, i32 undef>, <2 x i32> <i32 6, i32 7>
%op = sdiv <2 x i32> <i32 3333, i32 9999>, %select
ret <2 x i32> %op
}
define <2 x i32> @select_sdiv_rhs_const_v2i32(i1 %cond) {
; IR-LABEL: @select_sdiv_rhs_const_v2i32(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], <2 x i32> <i32 198621, i32 20855308>, <2 x i32> <i32 222748, i32 2338858>
; IR-NEXT: ret <2 x i32> [[OP]]
;
; GCN-LABEL: select_sdiv_rhs_const_v2i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x3661c
; GCN-NEXT: v_mov_b32_e32 v2, 0x307dd
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: v_mov_b32_e32 v1, 0x23b02a
; GCN-NEXT: v_mov_b32_e32 v2, 0x13e3a0c
; GCN-NEXT: v_cndmask_b32_e32 v1, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, <2 x i32> <i32 8342123, i32 834212353>, <2 x i32> <i32 9355456, i32 93554321>
%op = sdiv <2 x i32> %select, <i32 42, i32 40>
ret <2 x i32> %op
}
@gv = external addrspace(1) global i32
define i32 @select_sdiv_lhs_opaque_const0_i32(i1 %cond) {
; IR-LABEL: @select_sdiv_lhs_opaque_const0_i32(
; IR-NEXT: [[SELECT:%.*]] = select i1 [[COND:%.*]], i32 ptrtoint (i32 addrspace(1)* @gv to i32), i32 5
; IR-NEXT: [[TMP1:%.*]] = ashr i32 [[SELECT]], 31
; IR-NEXT: [[TMP2:%.*]] = xor i32 0, [[TMP1]]
; IR-NEXT: [[TMP3:%.*]] = add i32 [[SELECT]], [[TMP1]]
; IR-NEXT: [[TMP4:%.*]] = xor i32 [[TMP3]], [[TMP1]]
; IR-NEXT: [[TMP5:%.*]] = uitofp i32 [[TMP4]] to float
AMDGPU: Directly use rcp intrinsic in idiv expansions Since natural fdiv lowering is now more conservative even with denormals disabled, we get a slower expansion from just a plain 1.0/fdiv. Directly emit the rcp intrinsic when using it to implement integer division to avoid a pointlessly complex sequence.
2020-02-11 22:58:53 +08:00
; IR-NEXT: [[TMP6:%.*]] = call fast float @llvm.amdgcn.rcp.f32(float [[TMP5]])
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP7:%.*]] = fmul fast float [[TMP6]], 0x41EFFFFFC0000000
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; IR-NEXT: [[TMP8:%.*]] = fptoui float [[TMP7]] to i32
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP9:%.*]] = sub i32 0, [[TMP4]]
; IR-NEXT: [[TMP10:%.*]] = mul i32 [[TMP9]], [[TMP8]]
; IR-NEXT: [[TMP11:%.*]] = zext i32 [[TMP8]] to i64
; IR-NEXT: [[TMP12:%.*]] = zext i32 [[TMP10]] to i64
; IR-NEXT: [[TMP13:%.*]] = mul i64 [[TMP11]], [[TMP12]]
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; IR-NEXT: [[TMP14:%.*]] = trunc i64 [[TMP13]] to i32
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP15:%.*]] = lshr i64 [[TMP13]], 32
; IR-NEXT: [[TMP16:%.*]] = trunc i64 [[TMP15]] to i32
; IR-NEXT: [[TMP17:%.*]] = add i32 [[TMP8]], [[TMP16]]
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; IR-NEXT: [[TMP18:%.*]] = zext i32 [[TMP17]] to i64
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP19:%.*]] = mul i64 1000000, [[TMP18]]
; IR-NEXT: [[TMP20:%.*]] = trunc i64 [[TMP19]] to i32
; IR-NEXT: [[TMP21:%.*]] = lshr i64 [[TMP19]], 32
; IR-NEXT: [[TMP22:%.*]] = trunc i64 [[TMP21]] to i32
; IR-NEXT: [[TMP23:%.*]] = mul i32 [[TMP22]], [[TMP4]]
; IR-NEXT: [[TMP24:%.*]] = sub i32 1000000, [[TMP23]]
; IR-NEXT: [[TMP25:%.*]] = icmp uge i32 [[TMP24]], [[TMP4]]
; IR-NEXT: [[TMP26:%.*]] = add i32 [[TMP22]], 1
; IR-NEXT: [[TMP27:%.*]] = select i1 [[TMP25]], i32 [[TMP26]], i32 [[TMP22]]
; IR-NEXT: [[TMP28:%.*]] = sub i32 [[TMP24]], [[TMP4]]
; IR-NEXT: [[TMP29:%.*]] = select i1 [[TMP25]], i32 [[TMP28]], i32 [[TMP24]]
; IR-NEXT: [[TMP30:%.*]] = icmp uge i32 [[TMP29]], [[TMP4]]
; IR-NEXT: [[TMP31:%.*]] = add i32 [[TMP27]], 1
; IR-NEXT: [[TMP32:%.*]] = select i1 [[TMP30]], i32 [[TMP31]], i32 [[TMP27]]
; IR-NEXT: [[TMP33:%.*]] = xor i32 [[TMP32]], [[TMP2]]
; IR-NEXT: [[TMP34:%.*]] = sub i32 [[TMP33]], [[TMP2]]
; IR-NEXT: ret i32 [[TMP34]]
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
;
; GCN-LABEL: select_sdiv_lhs_opaque_const0_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: s_getpc_b64 s[4:5]
; GCN-NEXT: s_add_u32 s4, s4, gv@gotpcrel32@lo+4
[AMDGPU] Fix offset for REL32_HI relocs The addend in a REL32 reloc needs to be adjusted to account for the offset from the PC value returned by the s_getpc instruction to the point where the reloc is applied. This was being done correctly for (GOTPC)REL32_LO but not for (GOTPC)REL32_HI. This will only make a difference if the target symbol happens to get loaded almost exactly a multiple of 4G away from the relocated instructions. Differential Revision: https://reviews.llvm.org/D86938
2020-09-01 21:52:01 +08:00
; GCN-NEXT: s_addc_u32 s5, s5, gv@gotpcrel32@hi+12
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: s_load_dword s4, s[4:5], 0x0
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: s_waitcnt lgkmcnt(0)
; GCN-NEXT: v_mov_b32_e32 v1, s4
; GCN-NEXT: v_cndmask_b32_e32 v0, 5, v1, vcc
; GCN-NEXT: v_ashrrev_i32_e32 v1, 31, v0
; GCN-NEXT: v_add_u32_e32 v0, vcc, v0, v1
; GCN-NEXT: v_xor_b32_e32 v0, v0, v1
; GCN-NEXT: v_cvt_f32_u32_e32 v2, v0
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_sub_u32_e32 v3, vcc, 0, v0
; GCN-NEXT: s_mov_b32 s4, 0xf4240
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_rcp_iflag_f32_e32 v2, v2
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_mul_f32_e32 v2, 0x4f7ffffe, v2
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_cvt_u32_f32_e32 v2, v2
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_mul_lo_u32 v3, v3, v2
; GCN-NEXT: v_mul_hi_u32 v3, v2, v3
; GCN-NEXT: v_add_u32_e32 v2, vcc, v2, v3
; GCN-NEXT: v_mul_hi_u32 v2, v2, s4
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_mul_lo_u32 v3, v2, v0
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_add_u32_e32 v4, vcc, 1, v2
; GCN-NEXT: v_sub_u32_e32 v3, vcc, s4, v3
; GCN-NEXT: v_cmp_ge_u32_e32 vcc, v3, v0
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_cndmask_b32_e32 v2, v2, v4, vcc
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_sub_u32_e64 v4, s[4:5], v3, v0
; GCN-NEXT: v_cndmask_b32_e32 v3, v3, v4, vcc
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_add_u32_e32 v4, vcc, 1, v2
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_cmp_ge_u32_e32 vcc, v3, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v2, v4, vcc
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_xor_b32_e32 v0, v0, v1
; GCN-NEXT: v_sub_u32_e32 v0, vcc, v0, v1
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i32 ptrtoint (i32 addrspace(1)* @gv to i32), i32 5
%op = sdiv i32 1000000, %select
ret i32 %op
}
define i32 @select_sdiv_lhs_opaque_const1_i32(i1 %cond) {
; IR-LABEL: @select_sdiv_lhs_opaque_const1_i32(
; IR-NEXT: [[SELECT:%.*]] = select i1 [[COND:%.*]], i32 5, i32 ptrtoint (i32 addrspace(1)* @gv to i32)
; IR-NEXT: [[TMP1:%.*]] = ashr i32 [[SELECT]], 31
; IR-NEXT: [[TMP2:%.*]] = xor i32 0, [[TMP1]]
; IR-NEXT: [[TMP3:%.*]] = add i32 [[SELECT]], [[TMP1]]
; IR-NEXT: [[TMP4:%.*]] = xor i32 [[TMP3]], [[TMP1]]
; IR-NEXT: [[TMP5:%.*]] = uitofp i32 [[TMP4]] to float
AMDGPU: Directly use rcp intrinsic in idiv expansions Since natural fdiv lowering is now more conservative even with denormals disabled, we get a slower expansion from just a plain 1.0/fdiv. Directly emit the rcp intrinsic when using it to implement integer division to avoid a pointlessly complex sequence.
2020-02-11 22:58:53 +08:00
; IR-NEXT: [[TMP6:%.*]] = call fast float @llvm.amdgcn.rcp.f32(float [[TMP5]])
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP7:%.*]] = fmul fast float [[TMP6]], 0x41EFFFFFC0000000
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; IR-NEXT: [[TMP8:%.*]] = fptoui float [[TMP7]] to i32
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP9:%.*]] = sub i32 0, [[TMP4]]
; IR-NEXT: [[TMP10:%.*]] = mul i32 [[TMP9]], [[TMP8]]
; IR-NEXT: [[TMP11:%.*]] = zext i32 [[TMP8]] to i64
; IR-NEXT: [[TMP12:%.*]] = zext i32 [[TMP10]] to i64
; IR-NEXT: [[TMP13:%.*]] = mul i64 [[TMP11]], [[TMP12]]
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; IR-NEXT: [[TMP14:%.*]] = trunc i64 [[TMP13]] to i32
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP15:%.*]] = lshr i64 [[TMP13]], 32
; IR-NEXT: [[TMP16:%.*]] = trunc i64 [[TMP15]] to i32
; IR-NEXT: [[TMP17:%.*]] = add i32 [[TMP8]], [[TMP16]]
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; IR-NEXT: [[TMP18:%.*]] = zext i32 [[TMP17]] to i64
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: [[TMP19:%.*]] = mul i64 1000000, [[TMP18]]
; IR-NEXT: [[TMP20:%.*]] = trunc i64 [[TMP19]] to i32
; IR-NEXT: [[TMP21:%.*]] = lshr i64 [[TMP19]], 32
; IR-NEXT: [[TMP22:%.*]] = trunc i64 [[TMP21]] to i32
; IR-NEXT: [[TMP23:%.*]] = mul i32 [[TMP22]], [[TMP4]]
; IR-NEXT: [[TMP24:%.*]] = sub i32 1000000, [[TMP23]]
; IR-NEXT: [[TMP25:%.*]] = icmp uge i32 [[TMP24]], [[TMP4]]
; IR-NEXT: [[TMP26:%.*]] = add i32 [[TMP22]], 1
; IR-NEXT: [[TMP27:%.*]] = select i1 [[TMP25]], i32 [[TMP26]], i32 [[TMP22]]
; IR-NEXT: [[TMP28:%.*]] = sub i32 [[TMP24]], [[TMP4]]
; IR-NEXT: [[TMP29:%.*]] = select i1 [[TMP25]], i32 [[TMP28]], i32 [[TMP24]]
; IR-NEXT: [[TMP30:%.*]] = icmp uge i32 [[TMP29]], [[TMP4]]
; IR-NEXT: [[TMP31:%.*]] = add i32 [[TMP27]], 1
; IR-NEXT: [[TMP32:%.*]] = select i1 [[TMP30]], i32 [[TMP31]], i32 [[TMP27]]
; IR-NEXT: [[TMP33:%.*]] = xor i32 [[TMP32]], [[TMP2]]
; IR-NEXT: [[TMP34:%.*]] = sub i32 [[TMP33]], [[TMP2]]
; IR-NEXT: ret i32 [[TMP34]]
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
;
; GCN-LABEL: select_sdiv_lhs_opaque_const1_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: s_getpc_b64 s[4:5]
; GCN-NEXT: s_add_u32 s4, s4, gv@gotpcrel32@lo+4
[AMDGPU] Fix offset for REL32_HI relocs The addend in a REL32 reloc needs to be adjusted to account for the offset from the PC value returned by the s_getpc instruction to the point where the reloc is applied. This was being done correctly for (GOTPC)REL32_LO but not for (GOTPC)REL32_HI. This will only make a difference if the target symbol happens to get loaded almost exactly a multiple of 4G away from the relocated instructions. Differential Revision: https://reviews.llvm.org/D86938
2020-09-01 21:52:01 +08:00
; GCN-NEXT: s_addc_u32 s5, s5, gv@gotpcrel32@hi+12
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: s_load_dword s4, s[4:5], 0x0
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: s_waitcnt lgkmcnt(0)
; GCN-NEXT: v_mov_b32_e32 v1, s4
; GCN-NEXT: v_cndmask_b32_e64 v0, v1, 5, vcc
; GCN-NEXT: v_ashrrev_i32_e32 v1, 31, v0
; GCN-NEXT: v_add_u32_e32 v0, vcc, v0, v1
; GCN-NEXT: v_xor_b32_e32 v0, v0, v1
; GCN-NEXT: v_cvt_f32_u32_e32 v2, v0
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_sub_u32_e32 v3, vcc, 0, v0
; GCN-NEXT: s_mov_b32 s4, 0xf4240
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_rcp_iflag_f32_e32 v2, v2
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_mul_f32_e32 v2, 0x4f7ffffe, v2
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_cvt_u32_f32_e32 v2, v2
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_mul_lo_u32 v3, v3, v2
; GCN-NEXT: v_mul_hi_u32 v3, v2, v3
; GCN-NEXT: v_add_u32_e32 v2, vcc, v2, v3
; GCN-NEXT: v_mul_hi_u32 v2, v2, s4
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_mul_lo_u32 v3, v2, v0
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_add_u32_e32 v4, vcc, 1, v2
; GCN-NEXT: v_sub_u32_e32 v3, vcc, s4, v3
; GCN-NEXT: v_cmp_ge_u32_e32 vcc, v3, v0
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_cndmask_b32_e32 v2, v2, v4, vcc
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_sub_u32_e64 v4, s[4:5], v3, v0
; GCN-NEXT: v_cndmask_b32_e32 v3, v3, v4, vcc
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_add_u32_e32 v4, vcc, 1, v2
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; GCN-NEXT: v_cmp_ge_u32_e32 vcc, v3, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v2, v4, vcc
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_xor_b32_e32 v0, v0, v1
; GCN-NEXT: v_sub_u32_e32 v0, vcc, v0, v1
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i32 5, i32 ptrtoint (i32 addrspace(1)* @gv to i32)
%op = sdiv i32 1000000, %select
ret i32 %op
}
define i32 @select_sdiv_rhs_opaque_const0_i32(i1 %cond) {
; IR-LABEL: @select_sdiv_rhs_opaque_const0_i32(
; IR-NEXT: [[SELECT:%.*]] = select i1 [[COND:%.*]], i32 ptrtoint (i32 addrspace(1)* @gv to i32), i32 234234
; IR-NEXT: [[OP:%.*]] = sdiv i32 [[SELECT]], 42
; IR-NEXT: ret i32 [[OP]]
;
; GCN-LABEL: select_sdiv_rhs_opaque_const0_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: s_getpc_b64 s[4:5]
; GCN-NEXT: s_add_u32 s4, s4, gv@gotpcrel32@lo+4
[AMDGPU] Fix offset for REL32_HI relocs The addend in a REL32 reloc needs to be adjusted to account for the offset from the PC value returned by the s_getpc instruction to the point where the reloc is applied. This was being done correctly for (GOTPC)REL32_LO but not for (GOTPC)REL32_HI. This will only make a difference if the target symbol happens to get loaded almost exactly a multiple of 4G away from the relocated instructions. Differential Revision: https://reviews.llvm.org/D86938
2020-09-01 21:52:01 +08:00
; GCN-NEXT: s_addc_u32 s5, s5, gv@gotpcrel32@hi+12
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: s_load_dword s4, s[4:5], 0x0
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x392fa
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: s_waitcnt lgkmcnt(0)
; GCN-NEXT: v_mov_b32_e32 v2, s4
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
[AMDGPU] Remove dubious logic in bidirectional list scheduler Summary: pickNodeBidirectional tried to compare the best top candidate and the best bottom candidate by examining TopCand.Reason and BotCand.Reason. This is unsound because, after calling pickNodeFromQueue, Cand.Reason does not reflect the most important reason why Cand was chosen. Rather it reflects the most recent reason why it beat some other potential candidate, which could have been for some low priority tie breaker reason. I have seen this cause problems where TopCand is a good candidate, but because TopCand.Reason is ORDER (which is very low priority) it is repeatedly ignored in favour of a mediocre BotCand. This is not how bidirectional scheduling is supposed to work. To fix this I changed the code to always compare TopCand and BotCand directly, like the generic implementation of pickNodeBidirectional does. This removes some uncommented AMDGPU-specific logic; if this logic turns out to be important then perhaps it could be moved into an override of tryCandidate instead. Graphics shader benchmarking on gfx10 shows a lot more positive than negative effects from this change. Reviewers: arsenm, tstellar, rampitec, kzhuravl, vpykhtin, dstuttard, tpr, atrick, MatzeB Subscribers: jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68338
2019-10-07 22:33:59 +08:00
; GCN-NEXT: s_mov_b32 s4, 0x30c30c31
; GCN-NEXT: v_mul_hi_i32 v0, v0, s4
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_lshrrev_b32_e32 v1, 31, v0
; GCN-NEXT: v_ashrrev_i32_e32 v0, 3, v0
; GCN-NEXT: v_add_u32_e32 v0, vcc, v0, v1
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i32 ptrtoint (i32 addrspace(1)* @gv to i32), i32 234234
%op = sdiv i32 %select, 42
ret i32 %op
}
define i32 @select_sdiv_rhs_opaque_const1_i32(i1 %cond) {
; IR-LABEL: @select_sdiv_rhs_opaque_const1_i32(
; IR-NEXT: [[SELECT:%.*]] = select i1 [[COND:%.*]], i32 42000, i32 ptrtoint (i32 addrspace(1)* @gv to i32)
; IR-NEXT: [[OP:%.*]] = sdiv i32 [[SELECT]], 42
; IR-NEXT: ret i32 [[OP]]
;
; GCN-LABEL: select_sdiv_rhs_opaque_const1_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: s_getpc_b64 s[4:5]
; GCN-NEXT: s_add_u32 s4, s4, gv@gotpcrel32@lo+4
[AMDGPU] Fix offset for REL32_HI relocs The addend in a REL32 reloc needs to be adjusted to account for the offset from the PC value returned by the s_getpc instruction to the point where the reloc is applied. This was being done correctly for (GOTPC)REL32_LO but not for (GOTPC)REL32_HI. This will only make a difference if the target symbol happens to get loaded almost exactly a multiple of 4G away from the relocated instructions. Differential Revision: https://reviews.llvm.org/D86938
2020-09-01 21:52:01 +08:00
; GCN-NEXT: s_addc_u32 s5, s5, gv@gotpcrel32@hi+12
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: s_load_dword s4, s[4:5], 0x0
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0xa410
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: s_waitcnt lgkmcnt(0)
; GCN-NEXT: v_mov_b32_e32 v2, s4
; GCN-NEXT: v_cndmask_b32_e32 v0, v2, v1, vcc
[AMDGPU] Remove dubious logic in bidirectional list scheduler Summary: pickNodeBidirectional tried to compare the best top candidate and the best bottom candidate by examining TopCand.Reason and BotCand.Reason. This is unsound because, after calling pickNodeFromQueue, Cand.Reason does not reflect the most important reason why Cand was chosen. Rather it reflects the most recent reason why it beat some other potential candidate, which could have been for some low priority tie breaker reason. I have seen this cause problems where TopCand is a good candidate, but because TopCand.Reason is ORDER (which is very low priority) it is repeatedly ignored in favour of a mediocre BotCand. This is not how bidirectional scheduling is supposed to work. To fix this I changed the code to always compare TopCand and BotCand directly, like the generic implementation of pickNodeBidirectional does. This removes some uncommented AMDGPU-specific logic; if this logic turns out to be important then perhaps it could be moved into an override of tryCandidate instead. Graphics shader benchmarking on gfx10 shows a lot more positive than negative effects from this change. Reviewers: arsenm, tstellar, rampitec, kzhuravl, vpykhtin, dstuttard, tpr, atrick, MatzeB Subscribers: jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68338
2019-10-07 22:33:59 +08:00
; GCN-NEXT: s_mov_b32 s4, 0x30c30c31
; GCN-NEXT: v_mul_hi_i32 v0, v0, s4
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-NEXT: v_lshrrev_b32_e32 v1, 31, v0
; GCN-NEXT: v_ashrrev_i32_e32 v0, 3, v0
; GCN-NEXT: v_add_u32_e32 v0, vcc, v0, v1
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i32 42000, i32 ptrtoint (i32 addrspace(1)* @gv to i32)
%op = sdiv i32 %select, 42
ret i32 %op
}
define i32 @select_add_lhs_const_i32(i1 %cond) {
; IR-LABEL: @select_add_lhs_const_i32(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 1000005, i32 1000008
; IR-NEXT: ret i32 [[OP]]
;
; GCN-LABEL: select_add_lhs_const_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0xf4248
; GCN-NEXT: v_mov_b32_e32 v2, 0xf4245
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i32 5, i32 8
%op = add i32 1000000, %select
ret i32 %op
}
define float @select_fadd_lhs_const_i32_fmf(i1 %cond) {
; IR-LABEL: @select_fadd_lhs_const_i32_fmf(
; IR-NEXT: [[OP:%.*]] = select nnan nsz i1 [[COND:%.*]], float 3.000000e+00, float 5.000000e+00
; IR-NEXT: ret float [[OP]]
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
;
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-LABEL: select_fadd_lhs_const_i32_fmf:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x40a00000
; GCN-NEXT: v_mov_b32_e32 v2, 0x40400000
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, float 2.0, float 4.0
%op = fadd nnan nsz float 1.0, %select
ret float %op
}
; Make sure we don't try to use mul24 instead
define i32 @select_mul_lhs_const_i32(i1 %cond) {
; GCN-LABEL: select_mul_lhs_const_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x1f40
; GCN-NEXT: v_mov_b32_e32 v2, 0x1388
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
; IR-LABEL: @select_mul_lhs_const_i32(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 5000, i32 8000
; IR-NEXT: ret i32 [[OP]]
%select = select i1 %cond, i32 5, i32 8
%op = mul i32 1000, %select
ret i32 %op
}
; Make sure we don't try to use mul24 instead
define i32 @select_mul_rhs_const_i32(i1 %cond) {
; GCN-LABEL: select_mul_rhs_const_i32:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x1f40
; GCN-NEXT: v_mov_b32_e32 v2, 0x1388
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
; IR-LABEL: @select_mul_rhs_const_i32(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 5000, i32 8000
; IR-NEXT: ret i32 [[OP]]
%select = select i1 %cond, i32 5, i32 8
%op = mul i32 %select, 1000
ret i32 %op
}
define amdgpu_kernel void @select_add_lhs_const_i16(i1 %cond) {
AMDGPU: Look through casted selects to constant fold bin ops The promotion of the uniform select to i32 interfered with this fold.
2020-01-21 08:27:21 +08:00
; IR-LABEL: @select_add_lhs_const_i16(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i16 128, i16 131
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
; IR-NEXT: store i16 [[OP]], i16 addrspace(1)* undef, align 2
AMDGPU: Look through casted selects to constant fold bin ops The promotion of the uniform select to i32 interfered with this fold.
2020-01-21 08:27:21 +08:00
; IR-NEXT: ret void
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
;
AMDGPU: Do binop of select of constant fold in AMDGPUCodeGenPrepare DAGCombiner does this, but divisions expanded here miss this optimization. Since 67aa18f165640374cf0e0a6226dc793bbda6e74f, divisions have been expanded here and missed out on this optimization. Avoids test regressions in a future patch.
2020-01-20 02:24:47 +08:00
; GCN-LABEL: select_add_lhs_const_i16:
; GCN: ; %bb.0:
; GCN-NEXT: s_load_dword s0, s[4:5], 0x0
; GCN-NEXT: v_mov_b32_e32 v0, 0x83
; GCN-NEXT: v_mov_b32_e32 v1, 0x80
; GCN-NEXT: s_waitcnt lgkmcnt(0)
; GCN-NEXT: s_and_b32 s0, 1, s0
; GCN-NEXT: v_cmp_eq_u32_e64 vcc, s0, 1
; GCN-NEXT: v_cndmask_b32_e32 v0, v0, v1, vcc
; GCN-NEXT: flat_store_short v[0:1], v0
; GCN-NEXT: s_endpgm
%select = select i1 %cond, i16 5, i16 8
%op = add i16 %select, 123
store i16 %op, i16 addrspace(1)* undef
ret void
}
AMDGPU: Look through casted selects to constant fold bin ops The promotion of the uniform select to i32 interfered with this fold.
2020-01-21 08:27:21 +08:00
define i16 @select_add_trunc_select(i1 %cond) {
; GCN-LABEL: select_add_trunc_select:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e64 v0, 50, 47, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
; IR-LABEL: @select_add_trunc_select(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i16 47, i16 50
; IR-NEXT: ret i16 [[OP]]
%select = select i1 %cond, i32 5, i32 8
%trunc = trunc i32 %select to i16
%op = add i16 %trunc, 42
ret i16 %op
}
define i32 @select_add_sext_select(i1 %cond) {
; IR-LABEL: @select_add_sext_select(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 29, i32 50
; IR-NEXT: ret i32 [[OP]]
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
;
AMDGPU: Look through casted selects to constant fold bin ops The promotion of the uniform select to i32 interfered with this fold.
2020-01-21 08:27:21 +08:00
; GCN-LABEL: select_add_sext_select:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e64 v0, 50, 29, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i16 -13, i16 8
%trunc = sext i16 %select to i32
%op = add i32 %trunc, 42
ret i32 %op
}
define i32 @select_add_zext_select(i1 %cond) {
; IR-LABEL: @select_add_zext_select(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 47, i32 50
; IR-NEXT: ret i32 [[OP]]
[AMDGPU] Fix and simplify AMDGPUCodeGenPrepare::expandDivRem32 Fix the division/remainder algorithm by adding a second quotient refinement step, which is required in some cases like 0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212). Also document, rewrite and simplify it by ensuring that we always have a lower bound on inv(y), which simplifies the UNR step and the quotient refinement steps. Differential Revision: https://reviews.llvm.org/D83381
2020-06-22 22:27:37 +08:00
;
AMDGPU: Look through casted selects to constant fold bin ops The promotion of the uniform select to i32 interfered with this fold.
2020-01-21 08:27:21 +08:00
; GCN-LABEL: select_add_zext_select:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e64 v0, 50, 47, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, i16 5, i16 8
%trunc = zext i16 %select to i32
%op = add i32 %trunc, 42
ret i32 %op
}
AMDGPU: Check for other uses when looking through casted select Fixes mesa regression on ext_transform_feedback-max-varyings
2020-01-24 00:17:16 +08:00
define i32 @select_add_bitcast_select(i1 %cond) {
; IR-LABEL: @select_add_bitcast_select(
; IR-NEXT: [[OP:%.*]] = select i1 [[COND:%.*]], i32 1065353258, i32 1073741866
; IR-NEXT: ret i32 [[OP]]
;
; GCN-LABEL: select_add_bitcast_select:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x4000002a
; GCN-NEXT: v_mov_b32_e32 v2, 0x3f80002a
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, v1, v2, vcc
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, float 1.0, float 2.0
%trunc = bitcast float %select to i32
%op = add i32 %trunc, 42
ret i32 %op
}
; If we fold through a cast, we need to ensure it doesn't have
; multiple uses.
define <2 x half> @multi_use_cast_regression(i1 %cond) {
; IR-LABEL: @multi_use_cast_regression(
; IR-NEXT: [[SELECT:%.*]] = select i1 [[COND:%.*]], half 0xH3C00, half 0xH0000
; IR-NEXT: [[FPEXT:%.*]] = fpext half [[SELECT]] to float
; IR-NEXT: [[FSUB:%.*]] = fsub nsz float 1.000000e+00, [[FPEXT]]
; IR-NEXT: [[CALL:%.*]] = call nsz <2 x half> @llvm.amdgcn.cvt.pkrtz(float [[FPEXT]], float [[FSUB]])
; IR-NEXT: ret <2 x half> [[CALL]]
;
; GCN-LABEL: multi_use_cast_regression:
; GCN: ; %bb.0:
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
; GCN-NEXT: v_and_b32_e32 v0, 1, v0
; GCN-NEXT: v_mov_b32_e32 v1, 0x3c00
; GCN-NEXT: v_cmp_eq_u32_e32 vcc, 1, v0
; GCN-NEXT: v_cndmask_b32_e32 v0, 0, v1, vcc
; GCN-NEXT: v_cvt_f32_f16_e32 v0, v0
; GCN-NEXT: v_sub_f32_e32 v1, 1.0, v0
; GCN-NEXT: v_cvt_pkrtz_f16_f32 v0, v0, v1
; GCN-NEXT: s_setpc_b64 s[30:31]
%select = select i1 %cond, half 1.000000e+00, half 0.000000e+00
%fpext = fpext half %select to float
%fsub = fsub nsz float 1.0, %fpext
%call = call nsz <2 x half> @llvm.amdgcn.cvt.pkrtz(float %fpext, float %fsub) #3
ret <2 x half> %call
}
declare <2 x half> @llvm.amdgcn.cvt.pkrtz(float, float) #0
attributes #0 = { nounwind readnone speculatable }