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/regcoal-subrange-join-seg.mir

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

240 lines
6.0 KiB
Plaintext
Raw Normal View History

Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
# RUN: llc -march=amdgcn -run-pass simple-register-coalescing -o - %s | FileCheck --check-prefix=GCN %s
# REQUIRES: asserts
#
# This test will provoke a Couldn't join subrange unreachable without the
# fix for http://llvm.org/PR35373
#
# GCN: S_CBRANCH_SCC1 %bb.6, implicit undef $scc
--- |
define amdgpu_ps void @regcoal-subrange-join-seg() local_unnamed_addr #0 {
ret void
}
...
---
name: regcoal-subrange-join-seg
tracksRegLiveness: true
registers:
AMDGPU: Use SGPR_128 instead of SReg_128 for vregs SGPR_128 only includes the real allocatable SGPRs, and SReg_128 adds the additional non-allocatable TTMP registers. There's no point in allocating SReg_128 vregs. This shrinks the size of the classes regalloc needs to consider, which is usually good. llvm-svn: 374284
2019-10-10 15:11:33 +08:00
- { id: 0, class: sgpr_128 }
- { id: 1, class: sgpr_128 }
- { id: 2, class: sgpr_128 }
- { id: 3, class: sgpr_128 }
- { id: 4, class: sgpr_128 }
- { id: 5, class: sgpr_128 }
- { id: 6, class: sgpr_128 }
- { id: 7, class: sgpr_128 }
- { id: 8, class: sgpr_128 }
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
- { id: 9, class: sreg_32_xm0 }
- { id: 10, class: sreg_32_xm0 }
- { id: 11, class: vgpr_32 }
- { id: 12, class: vgpr_32 }
- { id: 13, class: vgpr_32 }
- { id: 14, class: sreg_32_xm0_xexec }
AMDGPU: Use SGPR_128 instead of SReg_128 for vregs SGPR_128 only includes the real allocatable SGPRs, and SReg_128 adds the additional non-allocatable TTMP registers. There's no point in allocating SReg_128 vregs. This shrinks the size of the classes regalloc needs to consider, which is usually good. llvm-svn: 374284
2019-10-10 15:11:33 +08:00
- { id: 15, class: sgpr_128 }
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
- { id: 16, class: sreg_32 }
- { id: 17, class: sreg_32_xm0 }
- { id: 18, class: sreg_32_xm0 }
- { id: 19, class: sreg_32_xm0 }
- { id: 20, class: sreg_32_xm0 }
- { id: 21, class: sreg_32_xm0_xexec }
AMDGPU: Use SGPR_128 instead of SReg_128 for vregs SGPR_128 only includes the real allocatable SGPRs, and SReg_128 adds the additional non-allocatable TTMP registers. There's no point in allocating SReg_128 vregs. This shrinks the size of the classes regalloc needs to consider, which is usually good. llvm-svn: 374284
2019-10-10 15:11:33 +08:00
- { id: 22, class: sgpr_128 }
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
- { id: 23, class: sreg_32_xm0 }
- { id: 24, class: vgpr_32 }
- { id: 25, class: sreg_64_xexec }
- { id: 26, class: vgpr_32 }
- { id: 27, class: sreg_32_xm0 }
- { id: 28, class: sreg_32 }
AMDGPU: Use SGPR_128 instead of SReg_128 for vregs SGPR_128 only includes the real allocatable SGPRs, and SReg_128 adds the additional non-allocatable TTMP registers. There's no point in allocating SReg_128 vregs. This shrinks the size of the classes regalloc needs to consider, which is usually good. llvm-svn: 374284
2019-10-10 15:11:33 +08:00
- { id: 29, class: sgpr_128 }
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
- { id: 30, class: sreg_32_xm0 }
- { id: 31, class: sreg_32_xm0 }
- { id: 32, class: vgpr_32 }
- { id: 33, class: vgpr_32 }
- { id: 34, class: vgpr_32 }
- { id: 35, class: vgpr_32 }
- { id: 36, class: vgpr_32 }
- { id: 37, class: vgpr_32 }
- { id: 38, class: vgpr_32 }
- { id: 39, class: vgpr_32 }
- { id: 40, class: vgpr_32 }
- { id: 41, class: vgpr_32 }
- { id: 42, class: vgpr_32 }
- { id: 43, class: vgpr_32 }
- { id: 44, class: vgpr_32 }
- { id: 45, class: vgpr_32 }
- { id: 46, class: vgpr_32 }
- { id: 47, class: vgpr_32 }
- { id: 48, class: vgpr_32 }
- { id: 49, class: vreg_128 }
- { id: 50, class: vreg_128 }
- { id: 51, class: vreg_128 }
- { id: 52, class: vreg_128 }
- { id: 53, class: vreg_128 }
- { id: 54, class: vreg_128 }
- { id: 55, class: vgpr_32 }
- { id: 56, class: vreg_128 }
- { id: 57, class: vreg_128 }
- { id: 58, class: vreg_128 }
- { id: 59, class: vreg_128 }
- { id: 60, class: vreg_128 }
- { id: 61, class: vreg_128 }
- { id: 62, class: vreg_128 }
- { id: 63, class: vreg_128 }
body: |
bb.0:
S_CBRANCH_SCC1 %bb.6, implicit undef $scc
S_BRANCH %bb.1
bb.1:
S_CBRANCH_SCC1 %bb.4, implicit undef $scc
S_BRANCH %bb.2
bb.2:
S_CBRANCH_SCC1 %bb.4, implicit undef $scc
S_BRANCH %bb.3
bb.3:
bb.4:
successors: %bb.5, %bb.6
S_CBRANCH_SCC1 %bb.6, implicit undef $scc
S_BRANCH %bb.5
bb.5:
bb.6:
S_CBRANCH_SCC1 %bb.14, implicit undef $scc
S_BRANCH %bb.7
bb.7:
S_CBRANCH_SCC1 %bb.9, implicit undef $scc
S_BRANCH %bb.8
bb.8:
bb.9:
successors: %bb.10, %bb.13
S_CBRANCH_SCC1 %bb.13, implicit undef $scc
S_BRANCH %bb.10
bb.10:
S_CBRANCH_SCC1 %bb.12, implicit undef $scc
S_BRANCH %bb.11
bb.11:
bb.12:
bb.13:
bb.14:
S_CBRANCH_SCC1 %bb.26, implicit undef $scc
S_BRANCH %bb.15
bb.15:
S_CBRANCH_SCC1 %bb.20, implicit undef $scc
S_BRANCH %bb.16
bb.16:
successors: %bb.17, %bb.19
S_CBRANCH_SCC1 %bb.19, implicit undef $scc
S_BRANCH %bb.17
bb.17:
successors: %bb.18, %bb.19
S_CBRANCH_SCC1 %bb.19, implicit undef $scc
S_BRANCH %bb.18
bb.18:
bb.19:
bb.20:
S_CBRANCH_SCC1 %bb.25, implicit undef $scc
S_BRANCH %bb.21
bb.21:
successors: %bb.22, %bb.24
S_CBRANCH_SCC1 %bb.24, implicit undef $scc
S_BRANCH %bb.22
bb.22:
successors: %bb.23, %bb.24
S_CBRANCH_SCC1 %bb.24, implicit undef $scc
S_BRANCH %bb.23
bb.23:
bb.24:
bb.25:
bb.26:
S_CBRANCH_SCC1 %bb.35, implicit undef $scc
S_BRANCH %bb.27
bb.27:
S_CBRANCH_SCC1 %bb.32, implicit undef $scc
S_BRANCH %bb.28
bb.28:
%9 = S_FF1_I32_B32 undef %10
[AMDGPU] Add _e64 suffix to VOP3 Insts Previously, instructions which could be expressed as VOP3 in addition to another encoding had a _e64 suffix on the tablegen record name, while those only available as VOP3 did not. With this patch, all VOP3s will have the _e64 suffix. The assembly does not change, only the mir. Reviewed By: foad Differential Revision: https://reviews.llvm.org/D94341 Change-Id: Ia8ec8890d47f8f94bbbdac43745b4e9dd2b03423
2021-01-08 02:56:02 +08:00
%13 = V_MAD_U32_U24_e64 killed %9, 48, 32, 0, implicit $exec
[AMDGPU] Use single cache policy operand Replace individual operands GLC, SLC, and DLC with a single cache_policy bitmask operand. This will reduce the number of operands in MIR and I hope the amount of code. These operands are mostly 0 anyway. Additional advantage that parser will accept these flags in any order unlike now. Differential Revision: https://reviews.llvm.org/D96469
2021-02-09 08:36:10 +08:00
%45 = BUFFER_LOAD_DWORD_OFFEN killed %13, undef %15, 0, 0, 0, 0, 0, implicit $exec :: (dereferenceable invariant load 4)
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
%46 = V_AND_B32_e32 1, killed %45, implicit $exec
[AMDGPU] Use single cache policy operand Replace individual operands GLC, SLC, and DLC with a single cache_policy bitmask operand. This will reduce the number of operands in MIR and I hope the amount of code. These operands are mostly 0 anyway. Additional advantage that parser will accept these flags in any order unlike now. Differential Revision: https://reviews.llvm.org/D96469
2021-02-09 08:36:10 +08:00
%21 = S_BUFFER_LOAD_DWORD_SGPR undef %22, undef %23, 0 :: (dereferenceable invariant load 4)
AMDGPU: Start adding MODE register uses to instructions This is the groundwork required to implement strictfp. For now, this should be NFC for regular instructoins (many instructions just gain an extra use of a reserved register). Regalloc won't rematerialize instructions with reads of physical registers, but we were suffering from that anyway with the exec reads. Should add it for all the related FP uses (possibly with some extras). I did not add it to either the gpr index mode instructions (or every single VALU instruction) since it's a ridiculous feature already modeled as an arbitrary side effect. Also work towards marking instructions with FP exceptions. This doesn't actually set the bit yet since this would start to change codegen. It seems nofpexcept is currently not implied from the regular IR FP operations. Add it to some MIR tests where I think it might matter.
2020-05-28 01:25:37 +08:00
%25 = nofpexcept V_CMP_GE_F32_e64 0, 0, 0, killed %21, 0, implicit $mode, implicit $exec
[AMDGPU] Asm/disasm v_cndmask_b32_e64 with abs/neg source modifiers This commit allows v_cndmask_b32_e64 with abs, neg source modifiers on src0, src1 to be assembled and disassembled. This does appear to be allowed, even though they are floating point modifiers and the operand type is b32. To do this, I added src0_modifiers and src1_modifiers to the MachineInstr, which involved fixing up several places in codegen and mir tests. Differential Revision: https://reviews.llvm.org/D59191 Change-Id: I69bf4a8c73ebc65744f6110bb8fc4e937d79fbea llvm-svn: 356398
2019-03-19 03:25:39 +08:00
%26 = V_CNDMASK_B32_e64 0, 0, 0, -1, killed %25, implicit $exec
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
%62 = IMPLICIT_DEF
bb.29:
successors: %bb.30(0x30000000), %bb.36(0x50000000)
%53 = COPY killed %62
AMDGPU: Rename add/sub with carry out instructions The hardware has created a real mess in the naming for add/sub, which have been renamed basically every generation. Switch the carry out pseudos to have the gfx9/gfx10 names. We were using the original SI/CI v_add_i32/v_sub_i32 names. Later targets reintroduced these names as carryless instructions with a saturating clamp bit, which we do not define. Do this rename so we can unambiguously add these missing instructions. The carry-in versions should also be renamed, but at least those had a consistent _u32 name to begin with. The 16-bit instructions were also renamed, but aren't ambiguous. This does regress assembler error message quality in some cases. In mismatched wave32/wave64 situations, this will switch from "unsupported instruction" to "invalid operand", with the error pointing at the wrong position. I couldn't quite follow how the assembler selects these, but the previous behavior seemed accidental to me. It looked like there was a partial attempt to handle this which was never completed (i.e. there is an AMDGPUOperand::isBoolReg but it isn't used for anything).
2020-07-14 21:18:36 +08:00
%47 = V_ADD_CO_U32_e32 -1, %46, implicit-def dead $vcc, implicit $exec
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
%48 = V_OR_B32_e32 killed %47, %26, implicit $exec
%49 = COPY %53
%49.sub2 = COPY undef %48
%51 = COPY killed %49
%51.sub3 = COPY undef %26
V_CMP_NE_U32_e32 0, killed %48, implicit-def $vcc, implicit $exec
$vcc = S_AND_B64 $exec, killed $vcc, implicit-def dead $scc
S_CBRANCH_VCCZ %bb.30, implicit killed $vcc
bb.36:
%63 = COPY killed %51
S_BRANCH %bb.31
bb.30:
[AMDGPU] Add _e64 suffix to VOP3 Insts Previously, instructions which could be expressed as VOP3 in addition to another encoding had a _e64 suffix on the tablegen record name, while those only available as VOP3 did not. With this patch, all VOP3s will have the _e64 suffix. The assembly does not change, only the mir. Reviewed By: foad Differential Revision: https://reviews.llvm.org/D94341 Change-Id: Ia8ec8890d47f8f94bbbdac43745b4e9dd2b03423
2021-01-08 02:56:02 +08:00
%33 = nofpexcept V_MAD_F32_e64 1, killed %53.sub0, 0, undef %34, 0, 0, 0, 0, implicit $mode, implicit $exec
AMDGPU: Start adding MODE register uses to instructions This is the groundwork required to implement strictfp. For now, this should be NFC for regular instructoins (many instructions just gain an extra use of a reserved register). Regalloc won't rematerialize instructions with reads of physical registers, but we were suffering from that anyway with the exec reads. Should add it for all the related FP uses (possibly with some extras). I did not add it to either the gpr index mode instructions (or every single VALU instruction) since it's a ridiculous feature already modeled as an arbitrary side effect. Also work towards marking instructions with FP exceptions. This doesn't actually set the bit yet since this would start to change codegen. It seems nofpexcept is currently not implied from the regular IR FP operations. Add it to some MIR tests where I think it might matter.
2020-05-28 01:25:37 +08:00
%35 = nofpexcept V_MAC_F32_e32 killed %33, undef %36, undef %35, implicit $mode, implicit $exec
%38 = nofpexcept V_MAX_F32_e32 0, killed %35, implicit $mode, implicit $exec
%39 = nofpexcept V_LOG_F32_e32 killed %38, implicit $mode, implicit $exec
%40 = nofpexcept V_MUL_F32_e32 killed %39, undef %41, implicit $mode, implicit $exec
%42 = nofpexcept V_EXP_F32_e32 killed %40, implicit $mode, implicit $exec
dead %43 = nofpexcept V_MUL_F32_e32 killed %42, undef %44, implicit $mode, implicit $exec
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
%63 = COPY killed %51
bb.31:
%52 = COPY killed %63
%62 = COPY killed %52
S_BRANCH %bb.29
bb.32:
S_CBRANCH_SCC1 %bb.34, implicit undef $scc
S_BRANCH %bb.33
bb.33:
bb.34:
bb.35:
[AMDGPU] Add support for immediate operand for S_ENDPGM Summary: Add support for immediate operand in S_ENDPGM Change-Id: I0c56a076a10980f719fb2a8f16407e9c301013f6 Reviewers: alexshap Subscribers: qcolombet, arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, tpr, t-tye, eraman, arphaman, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59213 llvm-svn: 355902
2019-03-12 17:52:58 +08:00
S_ENDPGM 0
Shrink interval after moving copy in removePartialRedundancy llvm-svn: 334963
2018-06-19 01:16:39 +08:00
...