RISC-V miss report READ vector register on v.move instruction

[santimc]

Work environment

Questions	Answers
System Capstone runs on OS/arch/bits	any
Capstone module affected	risc-v
Source of Capstone	git clone
Version/git commit	6.0.0-Alpha8

Steps to get the wrong result

With cstool:

cstool -d riscv64 d7600542
 0  d7 60 05 42  vmv.s.x        v1, a0
        ID: 1382 (vmv_s_x)
        op_count: 2
                operands[0].type: REG = v1
                operands[0].access: READ
                operands[1].type: REG = a0
                operands[1].access: READ

        Groups: HasVInstructions

Should classify v1 as WRITE

[santimc]

There is a similar issue with the accumulate instructions

 0  d7 a1 20 b6  vmacc.vv       v3, v1, v2
        ID: 1306 (vmacc_vv)
        op_count: 4
                operands[0].type: REG = v3
                operands[0].access: READ
                operands[1].type: REG = v1
                operands[1].access: READ
                operands[2].type: REG = v2
                operands[2].access: READ
                operands[3].type: REG = (null)
                operands[3].access: READ

        Groups: HasVInstructions

That put the register as READ, but should be as well in WRITE

[Rot127]

cc @moste00

[santimc]

I see that this discrepancies are being handled in void RISCV_add_missing_write_access(MCInst *MI) in arch/RISCV/RISCVMapping.c for compressed instructions. Maybe for accumulate and for fuse multiply-add instruction that have 4 operands this could be solved in a similar way but seems kind of hacky.

diff --git c/arch/RISCV/RISCVMapping.c w/arch/RISCV/RISCVMapping.c
index eebab84a..29d33ff3 100644
--- c/arch/RISCV/RISCVMapping.c
+++ w/arch/RISCV/RISCVMapping.c
@@ -307,11 +307,22 @@ void RISCV_add_missing_write_access(MCInst *MI)
 {
        if (!detail_is_set(MI))
                return;
-       if (!isCompressed(MI))
-               return;

        cs_riscv *riscv_details = RISCV_get_detail(MI);
        cs_riscv_op *ops = riscv_details->operands;
+
+       if (riscv_details->op_count == 4) {
+               for (unsigned int i = 0; i < riscv_details->op_count; i++) {
+                       if (ops[i].type == RISCV_OP_INVALID){
+                               ops[i] = ops[1];
+                               ops[i].access |= CS_AC_WRITE;
+                               }
+               }
+       }
+
+       if (!isCompressed(MI))
+               return;
+
        // make the detection condition as specific as possible
        // so it doesn't accidentally trigger for other cases
        if (riscv_details->op_count == 2 && ops[0].type == RISCV_OP_INVALID &&

But for instruction like vmv.s.x I don't see an elegant way to fix it.

I also would like to understand why are this instructions operands being miss classified. I see that this fields are set in const cs_ac_type mapping_get_Op_access on Mapping.c

[Rot127]

I think they are not classified as RW because the constraint is missing for the RVInstV definition.

Could it be that the write back version (defined with RVInstV2) was added in another ISA version?

Or does Capstone simply matches the wrong instruction, because it doesn't check some feature flag?

def VMV_X_S : RVInstV<0b010000, 0b00000, OPMVV, (outs GPR:$vd),
                      (ins VR:$vs2), "vmv.x.s", "$vd, $vs2">,
              Sched<[WriteVIMovVX, ReadVIMovVX]>;
let Constraints = "$vd = $vd_wb" in
def VMV_S_X : RVInstV2<0b010000, 0b00000, OPMVX, (outs VR:$vd_wb),
                      (ins VR:$vd, GPR:$rs1), "vmv.s.x", "$vd, $rs1">,
              Sched<[WriteVIMovXV, ReadVIMovXV, ReadVIMovXX]>;

@moste00 Should be able to spot the error more easily.