The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*).

Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are:

* Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones.

* Limited in which registers they can use (usually x8..x15).

* Often clobber their input operand instead of giving a free move.

Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture.

I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.