[PATCH] D105847: [AArch64] Prepare for changes to STEP_VECTOR.
Eli Friedman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 15 10:06:50 PDT 2021
efriedma added inline comments.
================
Comment at: llvm/lib/Target/AArch64/SVEInstrFormats.td:4924
+ (!cast<Instruction>(NAME # "_D") simm5_64b:$imm5, (!cast<Instruction>("MOVi64imm") imm:$imm))>;
+ def : Pat<(add (nxv2i64 (step_vector_oneuse (i64 !cast<ImmLeaf>("i64imm_32bit"):$imm))), (nxv2i64 (AArch64dup(simm5_64b:$imm5)))),
+ (!cast<Instruction>(NAME # "_D") simm5_64b:$imm5, (SUBREG_TO_REG (i64 0), (!cast<Instruction>("MOVi32imm") (!cast<SDNodeXForm>("trunc_imm") imm:$imm)), sub_32))>;
----------------
david-arm wrote:
> To be honest I find it a bit difficult to work out what's going on here and what pattern it's matching. Is it possible to point to a specific test that's defending this?
The patterns involving trunc_imm are there to ensure we generate MOVi32imm where legal, instead of MOVi64imm. Normally, the patterns for immediates would do that, but we aren't using the regular patterns here because the operand of step_vector isn't a normal register value.
In the assembly, this means we print "mov w8, #2222" instead of "mov x8, #2222". See, for example, mul_stepvector_nxv2i64.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105847/new/
https://reviews.llvm.org/D105847
More information about the llvm-commits
mailing list