You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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 e39dd9d, b2cc7ea and f3cf0a5.
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
orc.slli
, pretend you sawslliw
, 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 whilevalgrind --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
The text was updated successfully, but these errors were encountered: