Thanks to visit codestin.com
Credit goes to github.com

Skip to content

ZJIT: Split Send into Lookup+Call #13400

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

ZJIT: Split Send into Lookup+Call #13400

wants to merge 6 commits into from
+724 −502

Conversation

tekknolagi
Copy link
Contributor

@tekknolagi tekknolagi commented May 21, 2025 •
edited
Loading

Split SendWithoutBlock{,Direct} into LookupMethod and CallMethod. From there,
centralize the profile- and type-driven rewrites to one function:
optimize_lookup_method. This determines if we know the call target at compile
time.

Then, we can rewrite CallMethod to do something with a known-constant target.
If we know it at compile-time, we can specialize to CallCFunc or CallIseq
(or more, like a hypothetical GetInstanceVariable, in the future).

Also,

  • Add CmePtr as type alias alias
  • Add CallableMethodEntry to type lattice
  • Make CallData an alias for *const rb_call_data

Fixes Shopify#577

Co-authored-by: Aaron Patterson [email protected]

@tekknolagi tekknolagi changed the title Split Send into Lookup+Call ZJIT: Split Send into Lookup+Call May 21, 2025
@matzbot matzbot requested a review from a team May 21, 2025 14:53
@tekknolagi
Copy link
Contributor Author

I will absolutely be cleaning up the commits in this PR for rebasing

@tekknolagi
Copy link
Contributor Author

Also, I need to figure out some stuff before landing like a codegen implementation of CallMethod (is there a nice C function for this?) and a couple of other TODOs sprinkled throughout the changes

@k0kubun
Copy link
Member

k0kubun commented May 22, 2025

Is it intentional that the ZJIT CI is failing at the moment?

@tekknolagi
Copy link
Contributor Author

Well it's not exactly intentional but I don't have codegen for CallMethod because I can't figure out a way to do it yet :( It's currently crashing/assert failing/...

@tekknolagi
Copy link
Contributor Author

But if you have feedback on the rest of the (admittedly big, kind of disorganized) PR separate from that, I would be interested. The CallMethod codegen is hopefully separate/isolated enough

@launchable-app Launchable app
Copy link

launchable-app bot commented Jun 6, 2025 •
edited
Loading

❌ Tests Failed

✖️no tests failed ✔️61990 tests passed(1 flake)

@tekknolagi tekknolagi mentioned this pull request Jun 13, 2025
Open
@tekknolagi
ZJIT: Split constant optimization before other optimizations
9e4b269 
This helps method lookups get resolved.
@tekknolagi
This is the second dumbest bug
9545355
@tekknolagi
Some fixes
06ce6a3 
* Need to spill receiver and arguments to the VM stack as arguments
* Don't use cpush; cpush always pushes two words
* Save SP
* Align stack
@tekknolagi
Copy link
Contributor Author

Should we just set up a frame and shell out to vm_exec? This PR is getting way too old and I need the HIR stuff to land about a month ago

@XrXr
Copy link
Member

XrXr commented Jul 2, 2025

Should we just set up a frame and shell out to vm_exec?

That sounds as tricky as what you're doing right now, since we still need to switch on the CME type in static code, set up parameters and all that. Basically vm_call0_cme().

@tekknolagi
Copy link
Contributor Author

Augh. We really need these HIR changes to improve the optimizer. @XrXr and @k0kubun what do you think is the fastest way to get this thing merged?

@XrXr
Copy link
Member

XrXr commented Jul 2, 2025

Short of just breaking codegen for now, just debugging all the failures seems like the way to go. We can set up pairing sessions and whatnot. (BTW, CI isn't running now because of merge conflict)

@k0kubun
Copy link
Member

k0kubun commented Jul 2, 2025 •
edited
Loading

I wonder if you could have just split the HIR instruction in one PR and then worked on changing the generated code in another PR. You seem to have introduced NATIVE_STACK_PTR and changed how the stack is used, but is it mandatory to achieve "Split Send into Lookup+Call"? When it's hard to make it work, I would start from small changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

ZJIT: Split SendWithoutBlock into LookupMethod+CallMethod
3 participants
@tekknolagi @k0kubun @XrXr