Consider reworking VMERGE in assembly language to improve consistency

[jhauser-us]

Without changing anything about the hardware implementation of VMERGE, the handling of VMERGE in the assembly language could be changed to be more consistent with other vector instructions as well as with a possible scalar equivalent instruction.

As a general rule, the document says

Element operations that are masked off do not modify the destination vector register element

Other than the vector reduction instructions, which always write a scalar value to element 0 of a vector, it appears the only instruction that violates this rule is VMERGE (including VFMERGE). This exception for VMERGE is unnecessary and, I claim, unwise.

(I attempted a complete survey of the instructions, but there are many. If there are other rule-breakers I overlooked, they should also be reconsidered.)

There is no need to expose to the assembly language the fact that the hardware interprets bit vm (bit 25) of the OP-V instruction encoding differently for VMERGE. I believe it would be better, and not at all inconsistent with existing RISC-V practice, to declare the following:

• The version of VMERGE that has bit 25 = 0 is a separate instruction called VMV (more specifically, VMV.V.V, VMV.V.X, and VMV.V.I, I suppose).

• The VMERGE instruction is not officially a masked instruction, although the encoding for VMERGE has bit 25 = 1.

Consistent with this model, the assembly language for VMERGE would then specify the mask register operand as v0 instead of v0.t. In this way, the need to treat VMERGE as exceptional is pushed down a level, becoming an encoding exception instead of an odd semantic exception for programmers.

The B extension provides a similar instruction, but operating on scalars. This instruction is currently called CMOV, with this assembly language syntax:

CMOV dest, cond, case1, case0

Whatever name this instruction may finally have in the B extension (I'll call it SELECT), it would be best if the assembly language for VMERGE could be made consistent, like so:

VSELECT.VV vd, v0, vs1, vs2
VSELECT.VX vd, v0, rs1, vs2
VSELECT.VI vd, v0, imm, vs2

[aswaterman]

Funny, I split it into two instructions in my instruction decoder generator because it’s easier to capture the rs2/vm constraint that way.

I’m pretty agnostic to this issue, and feel that it could be handled fine with an assembler pseudoinstruction for VMV, while keeping VMEEGE as-is in the assembler.

[jhauser-us]

Andrew wrote:

I’m pretty agnostic to this issue, and feel that it could be handled fine with an assembler pseudoinstruction for VMV, while keeping VMEEGE as-is in the assembler.

So, "leave it alone", right? That's what we have already.

[aswaterman]

I guess “leave it alone” and “follow your recommendation” both seem OK to me, so maybe @kasanovic has an opinion.