Hacker News new | ask | show | jobs
by ptitSeb 1118 days ago
Yes, it would be more efficiant, but it will also be more costly to generate. It would also render the handling of Signal more tricky (need to always be able to go back from the RV64 address to the orignial x86_64 address in case of a SEGFAULT for example). Also, intra-block jump make this more complicated. Box64 does a limited full-block optimisation for the Flags handling and SSE/x87/MMX register attribution, but that's pretty much. Some constant propagation mecanism would be nice and could save a lot of opcode, but no worked as been done it that direction for now (maybe later, it always bother me when I look at generated code dump to see also those multiple constant assigned multiple time).
1 comments

Constant propagation and also tracking of nonzero bits has been a huge performance improvement in QEMU. The latter helps a lot with x86's automated zero extension, because if you know the high 32 bits are zero you can use a 64-bit move instead of an AND.

But QEMU only does one basic block at a time without jumps so it's relatively easy to implement.

(I tested "7z b" and QEMU user mode emulation is about 30% for x86-on-x86, I'm curious to see how it fares for x86-on-RISCV but I don't have a board to test on).