Closed
Bug 1491202
Opened 7 years ago
Closed 1 year ago
Try to use more relative jumps
Categories
(Core :: JavaScript Engine: JIT, enhancement, P3)
Core
JavaScript Engine: JIT
Tracking
()
RESOLVED
INCOMPLETE
| Tracking | Status | |
|---|---|---|
| firefox64 | --- | affected |
People
(Reporter: pbone, Unassigned)
Details
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.
Comment 1•7 years ago
|
||
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.
Comment 2•7 years ago
|
||
This is the intent of Cranelift encoding to be able to select the smallest jump instruction size when possible.
Priority: -- → P3
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•