A glimpse into V8 development for RISC-V

> 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!

>V8 emits a near-jump for all forward jumps. If the target ends up too far away, the near-jump target is adjusted to a jump pool entry that contains a long-jump to the actual target

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?

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:

    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.