Change disasm for vset{i}vli with reserved vtypes to display the reserved bits

[mehnadnerd]

Currently there is a bug with the disassembly when vsetivli/vsetvli have invalid vtypes (with reserved bits set). Spike correctly detects this and sets vill, but the disassembler integrated into spike ignores those bits being set and prints the instruction as if they weren't. This makes debugging harder, it looks like an otherwise valid vtype was being rejected and can lead down debugging paths like thinking the vector unit is configured incorrectly.

This commit changes the behaviour so that if these reserved bits are set, it prints out the hex value of the vtype. This is understood by the assembler. GCC disassembler prints out the decimal value of the vtype in this case, I think that hex value is clearer but I can change it if desired.

[jerryz123]

Can we just unconditionally display the raw hex for the written vtype?

[mehnadnerd]

We could, but I don't think that would be as useful, printing the decoded vtype is helpful for understanding what the instruction does.

[aswaterman]

I guess the question to @mehnadnerd is whether he wanted a visual cue that indicates the requested vtype value is one that would cause vill to be set. For that to happen, the disassembler needs to replicate the logic on the simulator side (which isn't totally trivial).

If not, then I agree unconditionally printing the hex value in parens, in addition to printing the disassembled arguments, is fine.

[jerryz123]

We could, but I don't think that would be as useful, printing the decoded vtype is helpful for understanding what the instruction does.

Sorry, I meant always print out both.

the disassembler needs to replicate the logic on the simulator side (which isn't totally trivial).

Yeah, my concern was primarily around maintaining that logic here as well. At a glance it doesn't look easy to reuse the code without copying it, or doing some refactoring of the simulator.

[mehnadnerd]

Always printing out both could work, but I still worry it could be misleading when reserved bits are set.

I only implemented the reserved bit check, not the other checks (like making sure the combination of LMUL and SEW fits with VLEN/ELEN), because of the comment in the vector spec recommending assemblers only warn in those cases. I don't think trying to cover all vill cases here is practical/even a good idea.

Also, for printing out both, wouldn't that break the ability to assemble what is created? Not sure how high priority that is.

Looking at gcc and clang, they seem to recognise plausible vtypes (clang even recognises sew>64 in its assembler, but not in its disassembler, testing on GCC showed it only recognised the currently available sew/lmul)[https://godbolt.org/z/cr1Y7cz4b].
When the vtype isn't one of them, they fallback to a decimal value.

I think the behaviour of clang/GCC here is what we should try to emulate, they provide the most information possible to the user, but never anything that is incorrect.

Clang's implementation is here: [https://github.com/llvm/llvm-project/blob/e04bf911113566cec2e399f0909aed4e5dc309a0/llvm/lib/Target/RISCV/MCTargetDesc/RISCVInstPrinter.cpp#L195], I think we should basically match that.

[aswaterman]

I guess this is OK, since we aren't trying to be pedantically accurate with respect to what this particular implementation supports (e.g. SEW=64 is illegal on Zve32x). Since we're being a bit sloppy, which is consistent with the disassembler's philosophy anyway, there isn't too much duplicated logic to maintain.