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/fold-operands-order.mir

42 lines
1009 B
Plaintext
Raw Normal View History

AMDGPU: Do operand folding in program order Before it was possible to partially fold use instructions before the defs. After the xor is folded into a copy, the same mov can end up in the fold list twice, so on the second attempt it will fail expecting to see a register to fold. llvm-svn: 305821
2017-06-21 02:56:32 +08:00
# RUN: llc -mtriple=amdgcn--amdhsa -mcpu=hawaii -verify-machineinstrs -run-pass si-fold-operands -o - %s | FileCheck -check-prefix=GCN %s
...
---
# Blocks should be processed in program order to make sure folds
# aren't made in users before the def is seen.
# GCN-LABEL: name: mov_in_use_list_2x{{$}}
MIR: Print the register class or bank in vreg defs This updates the MIRPrinter to include the regclass when printing virtual register defs, which is already valid syntax for the parser. That is, given 64 bit %0 and %1 in a "gpr" regbank, %1(s64) = COPY %0(s64) would now be written as %1:gpr(s64) = COPY %0(s64) While this change alone introduces a bit of redundancy with the registers block, it allows us to update the tests to be more concise and understandable and brings us closer to being able to remove the registers block completely. Note: We generally only print the class in defs, but there is one exception. If there are uses without any defs whatsoever, we'll print the class on all uses. I'm not completely convinced this comes up in meaningful machine IR, but for now the MIRParser and MachineVerifier both accept that kind of stuff, so we don't want to have a situation where we can print something we can't parse. llvm-svn: 316479
2017-10-25 02:04:54 +08:00
# GCN: %2:vgpr_32 = V_MOV_B32_e32 0, implicit %exec
# GCN-NEXT: %3:vgpr_32 = COPY undef %0
AMDGPU: Do operand folding in program order Before it was possible to partially fold use instructions before the defs. After the xor is folded into a copy, the same mov can end up in the fold list twice, so on the second attempt it will fail expecting to see a register to fold. llvm-svn: 305821
2017-06-21 02:56:32 +08:00
MIR: Print the register class or bank in vreg defs This updates the MIRPrinter to include the regclass when printing virtual register defs, which is already valid syntax for the parser. That is, given 64 bit %0 and %1 in a "gpr" regbank, %1(s64) = COPY %0(s64) would now be written as %1:gpr(s64) = COPY %0(s64) While this change alone introduces a bit of redundancy with the registers block, it allows us to update the tests to be more concise and understandable and brings us closer to being able to remove the registers block completely. Note: We generally only print the class in defs, but there is one exception. If there are uses without any defs whatsoever, we'll print the class on all uses. I'm not completely convinced this comes up in meaningful machine IR, but for now the MIRParser and MachineVerifier both accept that kind of stuff, so we don't want to have a situation where we can print something we can't parse. llvm-svn: 316479
2017-10-25 02:04:54 +08:00
# GCN: %1:vgpr_32 = V_MOV_B32_e32 0, implicit %exec
AMDGPU: Do operand folding in program order Before it was possible to partially fold use instructions before the defs. After the xor is folded into a copy, the same mov can end up in the fold list twice, so on the second attempt it will fail expecting to see a register to fold. llvm-svn: 305821
2017-06-21 02:56:32 +08:00
name: mov_in_use_list_2x
tracksRegLiveness: true
registers:
- { id: 0, class: vgpr_32, preferred-register: '' }
- { id: 1, class: vgpr_32, preferred-register: '' }
- { id: 2, class: vgpr_32, preferred-register: '' }
- { id: 3, class: vgpr_32, preferred-register: '' }
liveins:
body: |
bb.0:
successors: %bb.2
S_BRANCH %bb.2
bb.1:
successors: %bb.2
%2 = COPY %1
%3 = V_XOR_B32_e64 killed %2, undef %0, implicit %exec
bb.2:
successors: %bb.1
%1 = V_MOV_B32_e32 0, implicit %exec
S_BRANCH %bb.1
...