Skip to content
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

Implement the ref.cast Wasm GC instruction #9437

Merged
merged 1 commit into from
Oct 10, 2024

Conversation

fitzgen
Copy link
Member

@fitzgen fitzgen commented Oct 10, 2024

Just building on top of our existing ref.test support and trapping if the test fails.

@fitzgen fitzgen requested a review from a team as a code owner October 10, 2024 15:08
@fitzgen fitzgen requested review from alexcrichton and removed request for a team October 10, 2024 15:08
Comment on lines +2758 to +2785
Operator::RefCastNonNull { hty } => {
let r = state.pop1();
let heap_type = environ.convert_heap_type(*hty);
let cast_okay = environ.translate_ref_test(
builder,
WasmRefType {
heap_type,
nullable: false,
},
r,
)?;
environ.trapz(builder, cast_okay, crate::TRAP_CAST_FAILURE);
state.push1(r);
}
Operator::RefCastNullable { hty } => {
let r = state.pop1();
let heap_type = environ.convert_heap_type(*hty);
let cast_okay = environ.translate_ref_test(
builder,
WasmRefType {
heap_type,
nullable: true,
},
r,
)?;
environ.trapz(builder, cast_okay, crate::TRAP_CAST_FAILURE);
state.push1(r);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can sort of see how this is going to get used for BrOnCast and such as well. Would it make sense to update translate_ref_test with an argument along the lines of "what to do as the conclusion"? For example here the trapz could get propagated upwards to avoid creating so many basic blocks as part of translate_ref_test. For BrOnCast and friend it could be used for "I already created the blocks and I'm telling you where to jump".

Basically there's cleanups we can do here in the frontend which Cranelift will not do in the mid-end. I don't know whether the better answer is to invest in the mid-end, assume that MachBuffer cleans up everything, or try to produce better IR here in the first place.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, certain things like trapzs (and jumps/brifs for br_on_cast[_fail]) could be propagated backwards into the ref.test implementation. I think long-term we want the mid-end to be able to clean this stuff up, just from a separation-of-concerns point of view.

I can add an item to the running list of optimizations/code quality improvements for this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I just fear that we've talked for a very long time about theoretical mid-end cleanups to basic blocks but haven't gotten to them, so it seems like it's probably easier to do it here than the mid-end.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, quite possible it is easier in the front end for now. Either way, not doing it as part of this PR :)

@fitzgen fitzgen added this pull request to the merge queue Oct 10, 2024
Merged via the queue into bytecodealliance:main with commit d5652f5 Oct 10, 2024
39 checks passed
@fitzgen fitzgen deleted the ref-cast branch October 10, 2024 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants