JIT: Considering dropping 32-bit backends

[LekKit]

Why?

TLDR: You don't benefit from 32-bit JIT anyways, unless you're running an obscure riscv32 guest, for same reason they are not tested too well. This will not cause any functional breakage.

• There is no way to accelerate a 64-bit guest with a native 32-bit JIT as of now, as the middleware does not provide a way to lower 64-bit operations into 32-bit instructions
• RVJIT needs a big rework, including reimplementation of public backend interfaces and new native intrinsics
• Both arm32 and i386 are very lacking in advanced instructions and hold back the whole thing
• No one maintains the arm32 backend, i386 backend is held on tape and sticks as part of x86_64 backend
• Oh we have a riscv32 backend? I only remembered about it midway typing this, anyways the hardware where it could run is pretty much non-existent
• RVJIT Linker is not implemented for arm32, requiring fallback handling
• Focusing on 64-bit backends will allow to drop fallbacks for 32-bit hosts, use more advanced instructions like SSE2, ARM64 VFP/NEON, etc as a baseline
• This is not a feature breakage in any way, any non-JITed host target will continue to run guests via generic interpreter

Why not?

• Someone may want to accelerate riscv32 guests on dated host hardware (???)
• Respecting the author of the arm32 backend (Although I think the arm64 already serves this purpose and will serve us for the observable future)
• Maybe the RVVM v0.7 release will keep those backends alive a bit more for those reasons

Alternative

It might be a much better idea to implement a generic "glue" JIT backend which will copy-paste precompiled functions into native code sequences and have zero architecture-specific code in it. This would allow at least some amount of 64-bit guest acceleration, and support for various host architectures beyond arm32 and i386 with minimal efforts

[archanox]

[LekKit]

Seems that arm32 JIT backend miscompiles instructions in some cases

How to reproduce: Purposely break FPU tests by defining FPU_LIB_CONFORMING_SIGNALING_COMPARE for arm32 in src/fpu_lib.h, run tests, somehow the failure of fcmp tests will cause a JIT miscompilation and SIGILL.

[archanox]

[User-art-prog]

Someone may want to accelerate riscv32 guests on dated host hardware (???)

There are some Android devices still shipping with 32-bit kernel/userspace. From the Android 16 CCD:

If Handheld device implementations include greater than or equal to 2GB and less than 4GB of memory available to the kernel and userspace, they:
[7.6.1/H-SR-1] Are STRONGLY RECOMMENDED to support only 32-bit userspace (both apps and system code)
If Handheld device implementations include less than 2GB of memory available to the kernel and userspace, they:
[7.6.1/H-1-1] MUST only support a single ABI (either 64-bit only or 32-bit only).

The glue backend would probably work good enough for these devices, unless anyone wants to fix and extend the 32-bit backends to support riscv64. Distro support for riscv32 is virtually nonexistent outside of source-based distros (Gentoo, Buildroot, Yocto, etc).