mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-24 13:33:37 +02:00
65c28040ef
REG_SEQUENCE falls into the same category as COPY for operands mapping: - They don't have MCInstrDesc with register constraints - The input variable could use whatever register classes - It is possible to have register class already assigned to the operands In particular, given REG_SEQUENCE are always target specific because of the subreg indices. Those indices must apply to the register class of the definition of the REG_SEQUENCE and therefore, the target must set a register class to that definition. As a result, the generic code can always use that register class to derive a valid mapping for a REG_SEQUENCE. llvm-svn: 299285
26 lines
631 B
YAML
26 lines
631 B
YAML
# RUN: llc %s -mtriple aarch64-- -o - -run-pass regbankselect | FileCheck %s
|
|
--- |
|
|
define void @foo() { ret void }
|
|
...
|
|
---
|
|
# CHECK-LABEL: foo
|
|
# Check that we produce a valid mapping for REG_SEQUENCE.
|
|
# This used to fail the RegisterBankInfo verify because
|
|
# we were using the exclusively the type of the definition
|
|
# whereas since REG_SEQUENCE are kind of target opcode
|
|
# their definition may not have a type.
|
|
#
|
|
# CHECK: id: 0, class: dd
|
|
name: foo
|
|
legalized: true
|
|
tracksRegLiveness: true
|
|
registers:
|
|
- { id: 0, class: dd }
|
|
body: |
|
|
bb.0:
|
|
liveins: %d0, %d1
|
|
|
|
%0 = REG_SEQUENCE %d0, %subreg.dsub0, %d1, %subreg.dsub1
|
|
|
|
...
|