[llvm] [llvm-exegesis] [AArch64] Resolving "not all operands are initialized by snippet generator" (PR #142529)

Lakshay Kumar via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 20 04:03:54 PDT 2025


================
@@ -152,6 +163,66 @@ class ExegesisAArch64Target : public ExegesisTarget {
   }
 };
 
+Error ExegesisAArch64Target::randomizeTargetMCOperand(
+    const Instruction &Instr, const Variable &Var, MCOperand &AssignedValue,
+    const BitVector &ForbiddenRegs) const {
+  const Operand &Op = Instr.getPrimaryOperand(Var);
+  const auto OperandType = Op.getExplicitOperandInfo().OperandType;
+  //  FIXME: Implement opcode-specific immediate value handling for system
+  //  instructions:
+  //   - MRS/MSR: Use valid system register encodings (e.g., NZCV, FPCR, FPSR)
+  //   - MSRpstatesvcrImm1: Use valid PSTATE field encodings (e.g., SPSel,
+  //   DAIFSet)
+  //   - SYSLxt/SYSxt: Use valid system instruction encodings with proper
+  //   CRn/CRm/op values
+  //   - UDF: Use valid undefined instruction immediate ranges (0-65535)
+  //   Currently defaulting to immediate value 0, which may cause invalid
+  //   encodings or unreliable benchmark results for these system-level
+  //   instructions.
+  switch (OperandType) {
+  case MCOI::OperandType::OPERAND_UNKNOWN: {
+    AssignedValue = MCOperand::createImm(0);
+    return Error::success();
+  }
+  // MSL (Masking Shift Left) imm operand for 32-bit splatted SIMD constants
+  // Correspond to AArch64InstructionSelector::tryAdvSIMDModImm321s()
+  case llvm::AArch64::OPERAND_MSL_SHIFT: {
+    unsigned Opcode = Instr.getOpcode();
+    switch (Opcode) {
+    case AArch64::MOVIv2s_msl:
+    case AArch64::MVNIv2s_msl:
+      // Type 7: Pattern 0x00 0x00 abcdefgh 0xFF 0x00 0x00 abcdefgh 0xFF
+      // Creates 2-element 32-bit vector with 8-bit imm at positions [15:8] &
+      // [47:40] Shift value 264 (0x108) for Type 7 pattern encoding Corresponds
+      // to AArch64_AM::encodeAdvSIMDModImmType7()
+      AssignedValue = MCOperand::createImm(264);
----------------
lakshayk-nv wrote:

Sure, For simplicity we can use 264 (msl#8). As, there is no change in instruction characteristics (inverse_throughput), just the underlying generated assembly from msl #16 to msl #8

https://github.com/llvm/llvm-project/pull/142529


More information about the llvm-commits mailing list