A glimpse into V8 development for RISC-V(riseproject.dev)
riseproject.dev
A glimpse into V8 development for RISC-V
https://riseproject.dev/2025/12/09/a-glimpse-into-v8-development-for-risc-v/
8 comments
Sounds like it's probably emitting the machine code in a single pass (compilation speed matters for a browser JIT), perhaps even together in a single pass with lowering (so don't even know the amount of instructions beforehand), and for such adjusting things afterwards would mean parsing & rewriting bytecode, and adjusting already-hardcoded backwards jump distances.
Maybe they benchmarked it and processors are so good at predicting the indirection, it doesn't matter much. In out-of-order processors there is a lot of untapped potential. As an example, Rust inserts bounds checks almost for free.
Quote, because unlike on Reddit I couldn't figure out how to do multi para > quotes with code here.
------
Compressed pointers reduce the need for memory by storing pointers as 32-bit unsigned offsets relative to a base register. Decompressing the pointers just consists of adding the offset and register together. As simple as this sounds, it comes with a small complication on our RISC-V 64-bit port. By construction, 32-bit values are always loaded into the 64-bit registers as signed values. This means that we need to zero-extend the 32-bit offset first. Until recently this was done by bit-anding the register with 0xFFFF_FFFF:
This is so strange. Does no one at Google know RISC-V? This has *never* needed more than...
After all, `zext.w` is just an alias for `add.uw` with the `zero` register as the last argument...
They also could have always simply stored the 32 bit offset as signed and pointed the base register 2GB into the memory area instead of using x86/Arm-centric design.
------
Compressed pointers reduce the need for memory by storing pointers as 32-bit unsigned offsets relative to a base register. Decompressing the pointers just consists of adding the offset and register together. As simple as this sounds, it comes with a small complication on our RISC-V 64-bit port. By construction, 32-bit values are always loaded into the 64-bit registers as signed values. This means that we need to zero-extend the 32-bit offset first. Until recently this was done by bit-anding the register with 0xFFFF_FFFF:
li t3,1
slli t3, t3, 32
addi t3, t3, -1
and a0, a0, t3
zext.w a0, a0
This is so strange. Does no one at Google know RISC-V? This has *never* needed more than...
slli a0, a0, 32
srli a0, a0, 32
add.uw decompressed, compressed, base
After all, `zext.w` is just an alias for `add.uw` with the `zero` register as the last argument...
They also could have always simply stored the 32 bit offset as signed and pointed the base register 2GB into the memory area instead of using x86/Arm-centric design.
You are absolutely right, and a follow-up CL fixed the non-Zba code path. At the time of writing of the blog post, the generated code was however still using the 4 instructions instead of just two.
V8 is a huge project and ports almost have to start from backends of existing architectures. Over time we (I recently worked on the RISC-V port) improve the situation.
Note that it's also crucial to stay somehow similar to the x86 and ARM backends as the V8 team frequently makes changes to these and keeping up with them would be a nightmare if the RISC-V backend was too different.
"Does no one at Google know RISC-V" This work wasn't done by Google. Also, you don't hire RISC-V experts, but V8 experts (or other similar VMs) for such a port. I, for example, had never worked with RISC-V before. As such, it can happen that some code of the RISC-V backend is written by engineers that aren't yet experts in RISC-V.
V8 is a huge project and ports almost have to start from backends of existing architectures. Over time we (I recently worked on the RISC-V port) improve the situation.
Note that it's also crucial to stay somehow similar to the x86 and ARM backends as the V8 team frequently makes changes to these and keeping up with them would be a nightmare if the RISC-V backend was too different.
"Does no one at Google know RISC-V" This work wasn't done by Google. Also, you don't hire RISC-V experts, but V8 experts (or other similar VMs) for such a port. I, for example, had never worked with RISC-V before. As such, it can happen that some code of the RISC-V backend is written by engineers that aren't yet experts in RISC-V.
And, even if not that, the 0x0000_0000_FFFF_FFFF constant could be generated via 2 instrs of
li a0, -1
srli a0, a0, 32
> Does no one at Google know RISC-V?
These are not current Googlers.
These are not current Googlers.
> You can find more of these kinds of optimizations on SpacemiT’s blog post.
The linked article (<https://www.spacemit.com/news/%e8%bf%9b%e8%bf%ad%e6%97%b6%e7...>, in Chinese however) is definitely worth reading. Glad to have so much to learn about instruction selection!
The linked article (<https://www.spacemit.com/news/%e8%bf%9b%e8%bf%ad%e6%97%b6%e7...>, in Chinese however) is definitely worth reading. Glad to have so much to learn about instruction selection!
This sounds weird to me... Why not assume that all jumps need to be long to start with (so that the code is valid), then relax them to short jumps during an N-pass optimization stage- so that you get the smallest possible code?