[YJIT] Implement getblockparam #5881
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This implements the getblockparam instruction. There are two cases we need to handle depending on whether or not VM_FRAME_FLAG_MODIFIED_BLOCK_PARAM is set in the environment flag. When the modified flag is unset, we need to call rb_vm_bh_to_procval to get a proc from our passed block, save the proc in the environment, and set the modified flag. In the case that the modified flag is set we are able to just use the existing proc in the environment. One quirk of this is that we need to call jit_prepare_routine_call early and ensure we update PC and SP regardless of the branch taken, so that we have a consistent SP offset at the start of the next instruction. We considered using a chain guard to generate these two paths separately, but decided against it because it's very common to see both and the modified case is basically a subset of the instructions in the unmodified case. This includes tests for both getblockparam and getblockparamproxy which was previously missing a test.
maximecb
reviewed
May 12, 2022
Comment on lines
+5609
to
+5612
| // If the frame flag has been modified, then the actual proc value is | ||
| // already in the EP and we should just use the value. | ||
| let frame_flag_modified = cb.new_label("frame_flag_modified".to_string()); | ||
| jnz_label(cb, frame_flag_modified); |
There was a problem hiding this comment.
Is this use as a kind of caching mechanisms for successive calls to a block argument?
There was a problem hiding this comment.
Yeah that's the idea. If the code never reads from the block parameter there is no GC allocation to materialize it into a Ruby object.
maximecb
approved these changes
May 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements the getblockparam instruction.
There are two cases we need to handle depending on whether or not
VM_FRAME_FLAG_MODIFIED_BLOCK_PARAM is set in the environment flag.
When the modified flag is unset, we need to call rb_vm_bh_to_procval to
get a proc from our passed block, save the proc in the environment, and
set the modified flag.
In the case that the modified flag is set we are able to just use the
existing proc in the environment.
One quirk of this is that we need to call jit_prepare_routine_call early
and ensure we update PC and SP regardless of the branch taken, so that
we have a consistent SP offset at the start of the next instruction.
We considered using a chain guard to generate these two paths
separately, but decided against it because it's very common to see both
and the modified case is basically a subset of the instructions in the
unmodified case.
This includes tests for both getblockparam and getblockparamproxy which
was previously missing a test.