riscv64: Add Zba extension instructions

[afonso360]

👋 Hey,

This PR adds the instructions present in the Zba extension to the RISC-V 64 backend. The Zba extension contains instructions for address generation.

Here's a quick summary:

Mnemonic	Description
add.uw rd, rs1, rs2	Add unsigned word
sh1add rd, rs1, rs2	Shift left by 1 and add
sh1add.uw rd, rs1, rs2	Shift unsigned word left by 1 and add
sh2add rd, rs1, rs2	Shift left by 2 and add
sh2add.uw rd, rs1, rs2	Shift unsigned word left by 2 and add
sh3add rd, rs1, rs2	Shift left by 3 and add
sh3add.uw rd, rs1, rs2	Shift unsigned word left by 3 and add
slli.uw rd, rs1, imm	Shift-left unsigned word (Immediate)

Besides directly matching the above, we also add the zext.w mnemnoic which is essentially add.uw rd, rs, zero.

I've left this fuzzing overnight on a riscv64 machine and all seems ok so far.

[jameysharp]

I have a few requests but for the most part I think this looks correct!

[afonso360]

Thanks for reviewing this! I've also added a bunch more rules to the sextend+arithmetic pattern, those are all in the last commit. Let me know if you'd prefer that split into it's own PR.

Even with all those rules, I think they can still be generalized further. Especially the shifts with const imm, but I noticed that I could also cleanup the regular shift rules in the same way, so I've left those improvements for a future PR.

[jameysharp]

Looks great, thank you! One tiny whitespace fix but I think this is good to go.

A note for future work: the riscv64 implementation of Imm12::maybe_from_u64 has issues similar to the aarch64 version with assuming that the high bits of an iconst are sign-extended, when we want them to be zero-extended instead. I don't think this is a correctness issue, just the immediate-operand rules may not always match when you expect them to.

[afonso360]

I found another issue with the new shift rules, since they can have a i128 RHS we need to explicitly access the value regs. I've updated that commit, but I'm going to run the icache fuzzer for a bit to doublecheck that I haven't missed any other cases.

A note for future work: the riscv64 implementation of Imm12::maybe_from_u64 has issues similar to the aarch64 version with assuming that the high bits of an iconst are sign-extended, when we want them to be zero-extended instead. I don't think this is a correctness issue, just the immediate-operand rules may not always match when you expect them to.

🤔 Yeah, I should look into that.