You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a tail calling interpreter. I now propose to tightly couple that with the JIT, so we can tail call into the JIT and tail call out of it.
This has a few benefits:
No more C stack consumption by the JIT.
Much more efficient entry and exit of jitted code. OSR entry is just a single indirect jump.
We need to align the calling convention of the JIT and the tail calling interpreter. This will need careful benchmarking to make sure we don't regress JIT performance.
The tricky thing here is that it seems like every compiler is going to have their own incompatible ABI for __attribute__((preserve_none)). Meaning, even if GCC and MSVC support it, we're still not able to call directly between them if the JIT is compiled with Clang (which I don't see changing anytime soon).
At worst, though, we just have a little trampoline that moves the arguments around to the expected registers on the way in (depending on the exact ABI, we may need to do more, and do it on the way out, too). But at least it would get rid of the C stack consumption. It's an open question whether that's worth the effort involved to make it work (and keep it working).
I think this might still be worth pursuing. It needs to be opt-in though for platforms that control their entire build system and compiler ABI/preserve_none calling convention. Perhaps --enable-experimental-jit=yes-tailcall would be enough.
Activity
Fidget-Spinner commentedon Feb 7, 2025
cc @brandtbucher
[-]Grand unified tail-calling JIT[/-][+]Grand unified tail-calling[/+]brandtbucher commentedon Feb 12, 2025
The tricky thing here is that it seems like every compiler is going to have their own incompatible ABI for
__attribute__((preserve_none)). Meaning, even if GCC and MSVC support it, we're still not able to call directly between them if the JIT is compiled with Clang (which I don't see changing anytime soon).At worst, though, we just have a little trampoline that moves the arguments around to the expected registers on the way in (depending on the exact ABI, we may need to do more, and do it on the way out, too). But at least it would get rid of the C stack consumption. It's an open question whether that's worth the effort involved to make it work (and keep it working).
gh-129819: Allow tier2/JIT and tailcall (GH-129820)
picnixz commentedon Jul 12, 2025
Anything else to do here?
Fidget-Spinner commentedon Jul 21, 2025
@markshannon you're planning to do this right?
Fidget-Spinner commentedon Mar 23, 2026
I think this might still be worth pursuing. It needs to be opt-in though for platforms that control their entire build system and compiler ABI/
preserve_nonecalling convention. Perhaps--enable-experimental-jit=yes-tailcallwould be enough.