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

David Green via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 1 00:31:57 PDT 2025


================
@@ -229,6 +233,41 @@ 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;
+  // TODO: Look into immediate values to be opcode specific for
+  // MRS, MSR, MSRpstatesvcrImm1, SYSLxt, SYSxt, UDF (illegal instruction)
+  switch (OperandType) {
+  case MCOI::OperandType::OPERAND_UNKNOWN: {
+    unsigned Opcode = Instr.getOpcode();
+    switch (Opcode) {
+    case AArch64::MOVIv2s_msl:
+    case AArch64::MOVIv4s_msl:
+    case AArch64::MVNIv2s_msl:
+    case AArch64::MVNIv4s_msl:
----------------
davemgreen wrote:

See 1ae4726ba24de0b23a312b53fa9993ad9d5d166c for how the operands can be marked with certain types. In that case just OPERAND_IMMEDIATE which is fairly generic, but I believe will make llvm-exegesis pick as value of 1. (I didn't get very far in the past because of some of the more complex operands instructions, like arith_shifted_reg on ADDXrs).

Ideally OPERAND_IMMEDIATE operands would have some way in tablegen to validate the range of the immediates (or pick from a set, etc), but there doesn't seem to be a way to do that. If we do mark the operands as a sensible type then we can re-use the information for validating the immediates during codegen, as well as generating valid constants here. You can see OPERAND_REG_IMM_INT32 or something like OPERAND_UIMM7_LSB00 for how they can get used in other backends.

If we add a lot of opcodes to llvm-exegesis to special case generating constants for OPERAND_UNKNOWN then it feels like we add a lot of technical debt that will need to be rewritten in the future. My hope is that it is not much extra work to either just mark the operand as OPERAND_IMMEDIATE, or if that isn't the right constant then introduce a new OPERAND_ type and predicate the constant from that.

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


More information about the llvm-commits mailing list