Running RV32 code on RV64

[brucehoult]

Do you think it's feasible to make a tool for valgrind to convert RV32 code to RV64 on the fly?

e.g. see slli or c.slli, pretend you saw slliw, etc.

It seems that if you want to simply run the code then QEMU is faster. On my primes benchmark [1] running an RV64 binary on VisionFive 2 using qemu-riscv64-static gives a slowdown of 8x while valgrind --tool=none gives a 17x slowdown. qemu-riscv32-static (on rv64) is essentially the same speed as the rv64 version.

But valgrind has additional bug finding benefits.

Of course both of these are converting the RISC-V code to a generic IL and then JITing it back to RISC-V. It would be much more efficient to have something that knew it was doing RISC-V --> RISC-V and left most of the instructions untouched, only rewriting the needed instructions (which can result in code expansion because of e.g. c.slli not having a W equivalent in the C extension.

Thoughts?

I know the original VMWare did x86 -> x86 JIT, changing only the instructions that were virtualisation holes. I don't know if there is anything like that for RISC-V (which of course doesn't have virtualisation holes)

[1] http://hoult.org/primes.txt

[petrpavlu]

I doubt having such a tool would be viable. As you mention, Valgrind with its disassemble-and-resynthesize technique is generally quite heavy weight. I'd be also worried about doing syscall translation.

The VEX library historically had some support for archX->archY translation but I haven't heard about anyone using it in practice. Some relevant commits mentioning its state are e39dd9d073d7838252b2e3b5b7d1a873568390ed, b2cc7ea009ae4f0eaa1197ee6f5c07e0ee873b3a and f3cf0a5a6388741d7f6c1762dda299790c027532.

What would be the use case for this?