Support more than two register classes

[yuyang-ok]

Riscv architecture have three category of registers.
integer registers are "x0-x31",
float registers are "f0-f31".
vector registers are "v0-v31".
riscv registers are not so general purpose as other platform.

[cfallin]

Thanks @yuyang-ok -- we can possibly do this, but the issue is that we have a very tight bit-packing in Operand that leaves only one bit for the class.

We could add another bit (allowing four classes), but at the cost of the vreg index; this would limit the maximum vreg count to 1M rather than 2M. I'd rather try to avoid that if we can.

Another bit we could steal is in the "kind" field: we currently have two bits to support Use, Def, Mod. If we can eliminate all of the Mods in Cranelift's use of regalloc2, then we could shrink back to use/def only.

In the meantime, you could temporarily solve the problem by coarsening the allocation. In other words, treat float and vector registers as one "register" allocated all at once. If the regalloc gives you "float/vec 15", then you can use both f15 and v15. It is wasteful, but temporarily solves the problem until we can do better. Does that seem workable?

[yuyang-ok]

I can wait a little while,still have a lot work to do.

[yuyang-ok]

@cfallin are you working on remove and Mod and add Vector class??

[cfallin]

@yuyang-ok yes, we're actually making good progress toward that. I've merged a few PRs in Cranelift recently removing most uses of mod operands; there are just a few left in s390x.

[yuyang-ok]

are you modifing regalloc2?? maybe I can help a little to add Vector class register.

[cfallin]

Not yet -- we need to reclaim the bit in the 32-bit encoding of operands first, before we add another regclass. Otherwise we shrink the number of vregs that can be supported by half (from 2M to 1M), and this is starting to get small enough that people with very large inputs can hit it (e.g. bytecodealliance/wasmtime#4865).

[yuyang-ok]

@cfallin ok.