7 months ago
7 months ago


(Reporter: pbone, Unassigned)



Firefox Tracking Flags

(firefox64 affected)




7 months ago
I noticed that JITed code used a 64-bit absolute address as the target of a jump.  It seems that we generate code in a single pass and if a label is bound after it is used, then once bound the address it was bound two is written into the earlier jump instructions.  And to make it safe 64-bits of space was reserved.

Would it be possible to either generate relative jumps, which maybe requires multiple passes, and maybe is undesirable for baseline compilation.  Or if we're confident that the jump target will be nearby, reserve only 32bits and use a RIP-relative jump with a 32 relative address.  Would it be too slow to add an assertion or fallback if the relative address is bigger than 32 bits?  If there was a suitable fallback path we could use even shorter relative addressive, or at least test if it's worth-while.
For plain labels/jumps we should always use a 32-bit offset already, but it's possible we use a 64-bit immediate when jumping to other JitCodes etc.

The x64 backend also has jump table infrastructure for patchable jumps (we emit a jump with 32-bit offset but we jump to the jump table at the end of the code if the patched offset doesn't fit in 32 bits).

Maybe Cranelift will be able to use 2-byte short jumps even.
This is the intent of Cranelift encoding to be able to select the smallest jump instruction size when possible.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.