[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