riscv64: Introduce Compressed Instructions

[afonso360]

👋 Hey,

This PR makes introduces compressed instructions to the RISC-V backend as part of the C extension.

C extension introduction

The C Extension adds encodings for 16 bit instructions. These are allowed to be freely interleaved with uncompressed instructions (i.e. we don't need a mode switch like Thumb2).

Some C instruction formats cannot encode all registers, so they may only be emitted if they get assigned a certain physical register. Additionally C instructions (almost) always have an equivalent uncompressed instruction.

Implementation

I've implemented this as an encoding only change. So our VCode instructions remain the same, but if we happen to get the correct registers and all the stars line up we emit a compressed instruction instead of a full sized instruction.

Inst::emit is now split into 3 stages:

1. First we run the instruction through Inst::allocate which just transforms a Inst with virtual registers, into a Inst with physical registers
2. We then try to emit the instruction as a compressed instruction
   • This may fail, and that's ok
   • Since we now have the final physical registers we can check if it's possible to emit it as a compressed instruction
3. If the compressed emission fails we default to the uncompressed emission

This PR only enables 2 instructions c.add and c.mv. Both of these use the CR format which allows the full range of registers. However they are enough to get us into trouble. c.mv is emitted quite often, and is enough to "unalign" most of the rest of the code.

Issues with capstone

Capstone supports decoding C instructions with a separate "Extra Mode".

Capstone currently cannot decode a number of instructions that we emit (i.e Zca, Zcb, Zcs or Vector Instructions). This is normally ok since it emits a .byte ... directive and we can still read the V-Code to figure out what is going on.

If I enable this "Extra Mode" by default it tries to decode these unknown instructions as C instructions and makes the whole thing unreadable.

My solution for this was to make C a non default extension, and only enable the Extra Mode when C is enabled. This lets us keep the normal disassembly for all current test cases. Mixing C instructions and Vector instructions still makes the whole thing unreadable, but at least its not the common case.

Runtests

I've made pretty much all runtests run with C as well as without. Even if the runtest will never directly emits a C instruction, it can emit for example a c.mv and emit the rest of the instructions "unaligned" which is also a configuration worth testing.

---

This is built on top of #6988 so it's worth waiting for that to be merged before looking into this. Additionally, it's probably a good idea to review this commit by commit instead of all at once.

[github-actions]

Subscribe to Label Action

cc @cfallin, @fitzgen

This issue or pull request has been labeled: "cranelift", "cranelift:area:riscv64", "cranelift:meta", "isle"

Thus the following users have been cc'd because of the following labels:

• cfallin: isle
• fitzgen: isle

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

This all looks great to me, and thanks as always for the detail explanations!

Would it be possible to add detection of these features to cranelift/native?

[afonso360]

Would it be possible to add detection of these features to cranelift/native?

They should already be detected. has_c was already previously detected via HWCAP (although we didn't do too much with that information).

The rest of them (Zca, Zcd and Zcb) are detected via parsing /proc/cpuinfo. We don't have to do anything special to detect them because we currently just grab all of the extension names in the ISA string and try to enable the equivalent has_{extname} flag.