Skip to content

Grand unified tail-calling #129819

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Fidget-Spinner opened this issue Feb 7, 2025 · 2 comments
Open

Grand unified tail-calling #129819

Fidget-Spinner opened this issue Feb 7, 2025 · 2 comments
Assignees
Labels
topic-JIT type-feature A feature request or enhancement

Comments

@Fidget-Spinner
Copy link
Member

Fidget-Spinner commented Feb 7, 2025

Feature or enhancement

Proposal:

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:

  1. No more C stack consumption by the JIT.
  2. 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.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

@Fidget-Spinner Fidget-Spinner added the type-feature A feature request or enhancement label Feb 7, 2025
@Fidget-Spinner Fidget-Spinner self-assigned this Feb 7, 2025
@Fidget-Spinner
Copy link
Member Author

cc @brandtbucher

@Fidget-Spinner Fidget-Spinner changed the title Grand unified tail-calling JIT Grand unified tail-calling Feb 8, 2025
@brandtbucher
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-JIT type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants