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/GlobalISel/inst-select-fneg.mir

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

531 lines
15 KiB
Plaintext
Raw Normal View History

AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
# RUN: llc -march=amdgcn -mcpu=tahiti -run-pass=instruction-select -global-isel-abort=0 -verify-machineinstrs -o - %s | FileCheck -check-prefix=GCN %s
AMDGPU/GlobalISel: Fix some broken run lines llvm-svn: 371992
2019-09-16 22:14:40 +08:00
# RUN: llc -march=amdgcn -mcpu=fiji -run-pass=instruction-select -global-isel-abort=0 -verify-machineinstrs -o - %s | FileCheck -check-prefix=GCN %s
# RUN: llc -march=amdgcn -mcpu=gfx900 -run-pass=instruction-select -global-isel-abort=0 -verify-machineinstrs -o - %s | FileCheck -check-prefix=GCN %s
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
---
name: fneg_s32_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_s32_ss
; GCN: liveins: $sgpr0
; GCN: [[COPY:%[0-9]+]]:sreg_32 = COPY $sgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147483648
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[S_XOR_B32_:%[0-9]+]]:sreg_32 = S_XOR_B32 [[COPY]], [[S_MOV_B32_]], implicit-def $scc
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: $sgpr0 = COPY [[S_XOR_B32_]]
%0:sgpr(s32) = COPY $sgpr0
%1:sgpr(s32) = G_FNEG %0
$sgpr0 = COPY %1
...
---
name: fneg_s32_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0
; GCN-LABEL: name: fneg_s32_vv
; GCN: liveins: $vgpr0
; GCN: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147483648
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32 = V_XOR_B32_e32 [[S_MOV_B32_]], [[COPY]], implicit $exec
; GCN: $vgpr0 = COPY [[V_XOR_B32_e32_]]
%0:vgpr(s32) = COPY $vgpr0
%1:vgpr(s32) = G_FNEG %0
$vgpr0 = COPY %1
...
---
name: fneg_s32_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_s32_vs
; GCN: liveins: $sgpr0
; GCN: [[COPY:%[0-9]+]]:sgpr(s32) = COPY $sgpr0
; GCN: [[FNEG:%[0-9]+]]:vgpr_32(s32) = G_FNEG [[COPY]]
; GCN: $vgpr0 = COPY [[FNEG]](s32)
%0:sgpr(s32) = COPY $sgpr0
%1:vgpr(s32) = G_FNEG %0
$vgpr0 = COPY %1
...
---
name: fneg_s16_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_s16_ss
; GCN: liveins: $sgpr0
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[COPY:%[0-9]+]]:sreg_32 = COPY $sgpr0
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 32768
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[S_XOR_B32_:%[0-9]+]]:sreg_32 = S_XOR_B32 [[COPY]], [[S_MOV_B32_]], implicit-def $scc
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: $sgpr0 = COPY [[S_XOR_B32_]]
%0:sgpr(s32) = COPY $sgpr0
%1:sgpr(s16) = G_TRUNC %0
%2:sgpr(s16) = G_FNEG %1
%3:sgpr(s32) = G_ANYEXT %2
$sgpr0 = COPY %3
...
---
name: fneg_s16_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0
; GCN-LABEL: name: fneg_s16_vv
; GCN: liveins: $vgpr0
AMDGPU/GlobalISel: Fix VALU s16 fneg llvm-svn: 371948
2019-09-16 08:20:54 +08:00
; GCN: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 32768
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32 = V_XOR_B32_e32 [[S_MOV_B32_]], [[COPY]], implicit $exec
; GCN: $vgpr0 = COPY [[V_XOR_B32_e32_]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:vgpr(s32) = COPY $vgpr0
%1:vgpr(s16) = G_TRUNC %0
%2:vgpr(s16) = G_FNEG %1
%3:vgpr(s32) = G_ANYEXT %2
$vgpr0 = COPY %3
...
---
name: fneg_s16_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_s16_vs
; GCN: liveins: $sgpr0
; GCN: [[COPY:%[0-9]+]]:sgpr(s32) = COPY $sgpr0
; GCN: [[TRUNC:%[0-9]+]]:sgpr(s16) = G_TRUNC [[COPY]](s32)
; GCN: [[FNEG:%[0-9]+]]:vgpr_32(s16) = G_FNEG [[TRUNC]]
; GCN: [[COPY1:%[0-9]+]]:vgpr_32(s32) = COPY [[FNEG]](s16)
; GCN: $vgpr0 = COPY [[COPY1]](s32)
%0:sgpr(s32) = COPY $sgpr0
%1:sgpr(s16) = G_TRUNC %0
%2:vgpr(s16) = G_FNEG %1
%3:vgpr(s32) = G_ANYEXT %2
$vgpr0 = COPY %3
...
---
name: fneg_v2s16_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0_sgpr1
; GCN-LABEL: name: fneg_v2s16_ss
; GCN: liveins: $sgpr0_sgpr1
; GCN: [[COPY:%[0-9]+]]:sreg_32 = COPY $sgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147516416
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[S_XOR_B32_:%[0-9]+]]:sreg_32 = S_XOR_B32 [[COPY]], [[S_MOV_B32_]], implicit-def $scc
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: $sgpr0 = COPY [[S_XOR_B32_]]
%0:sgpr(<2 x s16>) = COPY $sgpr0
%1:sgpr(<2 x s16>) = G_FNEG %0
$sgpr0 = COPY %1
...
---
name: fneg_v2s16_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0
; GCN-LABEL: name: fneg_v2s16_vv
; GCN: liveins: $vgpr0
; GCN: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147516416
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32 = V_XOR_B32_e32 [[S_MOV_B32_]], [[COPY]], implicit $exec
; GCN: $vgpr0 = COPY [[V_XOR_B32_e32_]]
%0:vgpr(<2 x s16>) = COPY $vgpr0
%1:vgpr(<2 x s16>) = G_FNEG %0
$vgpr0 = COPY %1
...
---
name: fneg_v2s16_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_v2s16_vs
; GCN: liveins: $sgpr0
; GCN: [[COPY:%[0-9]+]]:sgpr(<2 x s16>) = COPY $sgpr0
; GCN: [[FNEG:%[0-9]+]]:vgpr_32(<2 x s16>) = G_FNEG [[COPY]]
; GCN: $vgpr0 = COPY [[FNEG]](<2 x s16>)
%0:sgpr(<2 x s16>) = COPY $sgpr0
%1:vgpr(<2 x s16>) = G_FNEG %0
$vgpr0 = COPY %1
...
---
name: fneg_s64_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0_sgpr1
; GCN-LABEL: name: fneg_s64_ss
; GCN: liveins: $sgpr0_sgpr1
AMDGPU/GlobalISel: Manually select scalar f64 G_FNEG This should be no problem to support with a pattern, but it turns out there are just too many yaks to shave. The main problem is in the DAG emitter, which I have no desire to sink effort into fixing. If we had a bit to disable patterns in the DAG importer, fixing the GlobalISelEmitter is more manageable.
2020-01-26 08:34:22 +08:00
; GCN: [[COPY:%[0-9]+]]:sreg_64 = COPY $sgpr0_sgpr1
; GCN: [[COPY1:%[0-9]+]]:sreg_32 = COPY [[COPY]].sub0
; GCN: [[COPY2:%[0-9]+]]:sreg_32 = COPY [[COPY]].sub1
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147483648
; GCN: [[S_XOR_B32_:%[0-9]+]]:sreg_32 = S_XOR_B32 [[COPY2]], [[S_MOV_B32_]], implicit-def $scc
; GCN: [[REG_SEQUENCE:%[0-9]+]]:sreg_64 = REG_SEQUENCE [[COPY1]], %subreg.sub0, [[S_XOR_B32_]], %subreg.sub1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[REG_SEQUENCE]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:sgpr(s64) = COPY $sgpr0_sgpr1
%1:sgpr(s64) = G_FNEG %0
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %1
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_s64_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0_vgpr1
; GCN-LABEL: name: fneg_s64_vv
; GCN: liveins: $vgpr0_vgpr1
GlobalISel/TableGen: Handle REG_SEQUENCE patterns The scalar f64 patterns don't work yet because they fail on multiple results from the unused implicit def of scc in the result bit operation. llvm-svn: 371542
2019-09-11 01:57:33 +08:00
; GCN: [[COPY:%[0-9]+]]:vreg_64 = COPY $vgpr0_vgpr1
; GCN: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 2147483648, implicit $exec
; GCN: [[COPY1:%[0-9]+]]:vgpr_32 = COPY [[COPY]].sub1
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32 = V_XOR_B32_e32 [[COPY1]], [[V_MOV_B32_e32_]], implicit $exec
; GCN: [[COPY2:%[0-9]+]]:vgpr_32 = COPY [[COPY]].sub0
; GCN: [[REG_SEQUENCE:%[0-9]+]]:vreg_64 = REG_SEQUENCE [[COPY2]], %subreg.sub0, [[V_XOR_B32_e32_]], %subreg.sub1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[REG_SEQUENCE]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:vgpr(s64) = COPY $vgpr0_vgpr1
%1:vgpr(s64) = G_FNEG %0
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %1
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_s64_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0_sgpr1
; GCN-LABEL: name: fneg_s64_vs
; GCN: liveins: $sgpr0_sgpr1
; GCN: [[COPY:%[0-9]+]]:sgpr(s64) = COPY $sgpr0_sgpr1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: [[FNEG:%[0-9]+]]:vgpr(s64) = G_FNEG [[COPY]]
; GCN: S_ENDPGM 0, implicit [[FNEG]](s64)
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:sgpr(s64) = COPY $sgpr0_sgpr1
%1:vgpr(s64) = G_FNEG %0
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %1
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_fabs_s32_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0_sgpr1
; GCN-LABEL: name: fneg_fabs_s32_ss
; GCN: liveins: $sgpr0_sgpr1
; GCN: [[COPY:%[0-9]+]]:sreg_32 = COPY $sgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147483648
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[S_OR_B32_:%[0-9]+]]:sreg_32 = S_OR_B32 [[COPY]], [[S_MOV_B32_]], implicit-def $scc
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[S_OR_B32_]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:sgpr(s32) = COPY $sgpr0
%1:sgpr(s32) = G_FABS %0
%2:sgpr(s32) = G_FNEG %1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %2
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_fabs_s32_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0
; GCN-LABEL: name: fneg_fabs_s32_vv
; GCN: liveins: $vgpr0
; GCN: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147483648
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32 = V_XOR_B32_e32 [[S_MOV_B32_]], [[COPY]], implicit $exec
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[V_XOR_B32_e32_]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:vgpr(s32) = COPY $vgpr0
%1:vgpr(s32) = G_FABS %0
%2:vgpr(s32) = G_FNEG %0
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %2
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_fabs_s32_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_fabs_s32_vs
; GCN: liveins: $sgpr0
; GCN: [[COPY:%[0-9]+]]:sgpr(s32) = COPY $sgpr0
; GCN: [[FABS:%[0-9]+]]:vgpr_32(s32) = G_FABS [[COPY]]
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32(s16) = S_MOV_B32 2147483648
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32(s32) = V_XOR_B32_e32 [[S_MOV_B32_]](s16), [[FABS]](s32), implicit $exec
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[V_XOR_B32_e32_]](s32)
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:sgpr(s32) = COPY $sgpr0
%1:vgpr(s32) = G_FABS %0
%2:vgpr(s32) = G_FNEG %1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %2
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_fabs_s16_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_fabs_s16_ss
; GCN: liveins: $sgpr0
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[COPY:%[0-9]+]]:sreg_32 = COPY $sgpr0
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 32768
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[S_OR_B32_:%[0-9]+]]:sreg_32 = S_OR_B32 [[COPY]], [[S_MOV_B32_]], implicit-def $scc
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: $sgpr0 = COPY [[S_OR_B32_]]
%0:sgpr(s32) = COPY $sgpr0
%1:sgpr(s16) = G_TRUNC %0
%2:sgpr(s16) = G_FABS %1
%3:sgpr(s16) = G_FNEG %2
%4:sgpr(s32) = G_ANYEXT %3
$sgpr0 = COPY %4
...
---
name: fneg_fabs_s16_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0
; GCN-LABEL: name: fneg_fabs_s16_vv
; GCN: liveins: $vgpr0
AMDGPU/GlobalISel: Fix VALU s16 fneg llvm-svn: 371948
2019-09-16 08:20:54 +08:00
; GCN: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 32768
; GCN: [[V_OR_B32_e32_:%[0-9]+]]:vgpr_32 = V_OR_B32_e32 [[S_MOV_B32_]], [[COPY]], implicit $exec
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[COPY1:%[0-9]+]]:sreg_32 = COPY [[V_OR_B32_e32_]]
AMDGPU/GlobalISel: Fix VALU s16 fneg llvm-svn: 371948
2019-09-16 08:20:54 +08:00
; GCN: $vgpr0 = COPY [[COPY1]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:vgpr(s32) = COPY $vgpr0
%1:vgpr(s16) = G_TRUNC %0
%2:vgpr(s16) = G_FABS %1
%3:vgpr(s16) = G_FNEG %2
%4:sgpr(s32) = G_ANYEXT %3
$vgpr0 = COPY %4
...
---
name: fneg_fabs_s16_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_fabs_s16_vs
; GCN: liveins: $sgpr0
; GCN: [[COPY:%[0-9]+]]:sgpr(s32) = COPY $sgpr0
; GCN: [[TRUNC:%[0-9]+]]:sgpr(s16) = G_TRUNC [[COPY]](s32)
; GCN: [[FNEG:%[0-9]+]]:sgpr(s16) = G_FNEG [[TRUNC]]
; GCN: [[FNEG1:%[0-9]+]]:vgpr_32(s16) = G_FNEG [[FNEG]]
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[COPY1:%[0-9]+]]:sreg_32(s32) = COPY [[FNEG1]](s16)
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: $vgpr0 = COPY [[COPY1]](s32)
%0:sgpr(s32) = COPY $sgpr0
%1:sgpr(s16) = G_TRUNC %0
%2:sgpr(s16) = G_FNEG %1
%3:vgpr(s16) = G_FNEG %2
%4:sgpr(s32) = G_ANYEXT %3
$vgpr0 = COPY %4
...
---
name: fneg_fabs_v2s16_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0_sgpr1
; GCN-LABEL: name: fneg_fabs_v2s16_ss
; GCN: liveins: $sgpr0_sgpr1
; GCN: [[COPY:%[0-9]+]]:sreg_32 = COPY $sgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147516416
AMDGPU: Relax 32-bit SGPR register class Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
2019-10-19 02:26:37 +08:00
; GCN: [[S_OR_B32_:%[0-9]+]]:sreg_32 = S_OR_B32 [[COPY]], [[S_MOV_B32_]], implicit-def $scc
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
; GCN: $sgpr0 = COPY [[S_OR_B32_]]
%0:sgpr(<2 x s16>) = COPY $sgpr0
%1:sgpr(<2 x s16>) = G_FABS %0
%2:sgpr(<2 x s16>) = G_FNEG %1
$sgpr0 = COPY %2
...
---
name: fneg_fabs_v2s16_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0
; GCN-LABEL: name: fneg_fabs_v2s16_vv
; GCN: liveins: $vgpr0
; GCN: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147516416
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32 = V_XOR_B32_e32 [[S_MOV_B32_]], [[COPY]], implicit $exec
; GCN: $vgpr0 = COPY [[V_XOR_B32_e32_]]
%0:vgpr(<2 x s16>) = COPY $vgpr0
%1:vgpr(<2 x s16>) = G_FABS %0
%2:vgpr(<2 x s16>) = G_FNEG %0
$vgpr0 = COPY %2
...
---
name: fneg_fabs_v2s16_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0
; GCN-LABEL: name: fneg_fabs_v2s16_vs
; GCN: liveins: $sgpr0
; GCN: [[COPY:%[0-9]+]]:sgpr(<2 x s16>) = COPY $sgpr0
; GCN: [[FABS:%[0-9]+]]:vgpr_32(<2 x s16>) = G_FABS [[COPY]]
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32(s16) = S_MOV_B32 2147516416
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32(<2 x s16>) = V_XOR_B32_e32 [[S_MOV_B32_]](s16), [[FABS]](<2 x s16>), implicit $exec
; GCN: $vgpr0 = COPY [[V_XOR_B32_e32_]](<2 x s16>)
%0:sgpr(<2 x s16>) = COPY $sgpr0
%1:vgpr(<2 x s16>) = G_FABS %0
%2:vgpr(<2 x s16>) = G_FNEG %1
$vgpr0 = COPY %2
...
---
name: fneg_fabs_s64_ss
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0_sgpr1
; GCN-LABEL: name: fneg_fabs_s64_ss
; GCN: liveins: $sgpr0_sgpr1
AMDGPU/GlobalISel: Manually select scalar f64 G_FNEG This should be no problem to support with a pattern, but it turns out there are just too many yaks to shave. The main problem is in the DAG emitter, which I have no desire to sink effort into fixing. If we had a bit to disable patterns in the DAG importer, fixing the GlobalISelEmitter is more manageable.
2020-01-26 08:34:22 +08:00
; GCN: [[COPY:%[0-9]+]]:sreg_64 = COPY $sgpr0_sgpr1
; GCN: [[COPY1:%[0-9]+]]:sreg_32 = COPY [[COPY]].sub0
; GCN: [[COPY2:%[0-9]+]]:sreg_32 = COPY [[COPY]].sub1
; GCN: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 2147483648
; GCN: [[S_OR_B32_:%[0-9]+]]:sreg_32 = S_OR_B32 [[COPY2]], [[S_MOV_B32_]], implicit-def $scc
; GCN: [[REG_SEQUENCE:%[0-9]+]]:sreg_64 = REG_SEQUENCE [[COPY1]], %subreg.sub0, [[S_OR_B32_]], %subreg.sub1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[REG_SEQUENCE]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:sgpr(s64) = COPY $sgpr0_sgpr1
%1:sgpr(s64) = G_FABS %0
%2:sgpr(s64) = G_FNEG %1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %2
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_fabs_s64_vv
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0_vgpr1
; GCN-LABEL: name: fneg_fabs_s64_vv
; GCN: liveins: $vgpr0_vgpr1
GlobalISel/TableGen: Handle REG_SEQUENCE patterns The scalar f64 patterns don't work yet because they fail on multiple results from the unused implicit def of scc in the result bit operation. llvm-svn: 371542
2019-09-11 01:57:33 +08:00
; GCN: [[COPY:%[0-9]+]]:vreg_64 = COPY $vgpr0_vgpr1
; GCN: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 2147483648, implicit $exec
; GCN: [[COPY1:%[0-9]+]]:vgpr_32 = COPY [[COPY]].sub1
; GCN: [[V_OR_B32_e32_:%[0-9]+]]:vgpr_32 = V_OR_B32_e32 [[COPY1]], [[V_MOV_B32_e32_]], implicit $exec
; GCN: [[COPY2:%[0-9]+]]:vgpr_32 = COPY [[COPY]].sub0
; GCN: [[REG_SEQUENCE:%[0-9]+]]:vreg_64 = REG_SEQUENCE [[COPY2]], %subreg.sub0, [[V_OR_B32_e32_]], %subreg.sub1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[REG_SEQUENCE]]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:vgpr(s64) = COPY $vgpr0_vgpr1
%1:vgpr(s64) = G_FABS %0
%2:vgpr(s64) = G_FNEG %1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %2
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...
---
name: fneg_fabs_s64_vs
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $sgpr0_sgpr1
; GCN-LABEL: name: fneg_fabs_s64_vs
; GCN: liveins: $sgpr0_sgpr1
; GCN: [[COPY:%[0-9]+]]:sgpr(s64) = COPY $sgpr0_sgpr1
GlobalISel/TableGen: Handle REG_SEQUENCE patterns The scalar f64 patterns don't work yet because they fail on multiple results from the unused implicit def of scc in the result bit operation. llvm-svn: 371542
2019-09-11 01:57:33 +08:00
; GCN: [[FABS:%[0-9]+]]:vreg_64(s64) = G_FABS [[COPY]]
; GCN: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32(s32) = V_MOV_B32_e32 2147483648, implicit $exec
; GCN: [[COPY1:%[0-9]+]]:vgpr_32(s32) = COPY [[FABS]].sub1(s64)
; GCN: [[V_XOR_B32_e32_:%[0-9]+]]:vgpr_32(s16) = V_XOR_B32_e32 [[COPY1]](s32), [[V_MOV_B32_e32_]](s32), implicit $exec
; GCN: [[COPY2:%[0-9]+]]:vgpr_32(s32) = COPY [[FABS]].sub0(s64)
; GCN: [[REG_SEQUENCE:%[0-9]+]]:vreg_64(s64) = REG_SEQUENCE [[COPY2]](s32), %subreg.sub0, [[V_XOR_B32_e32_]](s16), %subreg.sub1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
; GCN: S_ENDPGM 0, implicit [[REG_SEQUENCE]](s64)
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
%0:sgpr(s64) = COPY $sgpr0_sgpr1
%1:vgpr(s64) = G_FABS %0
%2:vgpr(s64) = G_FNEG %1
TableGen/GlobalISel: Fix constraining REG_SEQUENCE operands This was hitting the default instruction constraint code which uses the register classes in the instruction def, which REG_SEQUENCE does not have. Fixes not constraining the register class for AMDGPU fneg/fabs patterns, which would fail when the use was another generic, unconstrained instruction. Another oddity I noticed is that the temporary registers are created with an unnecessary, but incorrect 16-bit LLT but this shouldn't matter. I'm also still unclear why root and sub-instructions have to be handled differently.
2020-04-07 21:32:51 +08:00
S_ENDPGM 0, implicit %2
AMDGPU/GlobalISel: Select G_FABS/G_FNEG f64 doesn't work yet because tablegen currently doesn't handlde REG_SEQUENCE. This does regress some multi use VALU fneg cases since now the immediate remains in an SGPR, and more moves are used for legalizing the xor. This is a SIFixSGPRCopies deficiency. llvm-svn: 371540
2019-09-11 01:19:46 +08:00
...