Implement subtype checking for [return_]call_indirect instructions#9448
Conversation
fitzgen
requested review from
alexcrichton and
cfallin
and removed request for
a team
When Wasm GC is enabled, the `[return_]call_indirect` instructions must do full subtyping checks, rather than simple strict equality type checks. This adds an additional branch and slow path to indirect calls, so we only emit code for this check when Wasm GC is enabled, even though it would otherwise be correct to always emit it (because the `is_subtype` check would always fail for non-equal types, since there is no subtyping before Wasm GC).
fitzgen
force-pushed
the
subtype-checking-for-call-indirect
branch
from
70bfce2 to
b89dcb6
Compare
alexcrichton
left a comment
alexcrichton
left a comment
There was a problem hiding this comment.
Mind filing an issue for this performance issue as well? This to me is going to be a hard blocker for enabling GC by default because a failed subtype check will involve acquiring a global lock even for non-GC modules which may not be appropriate for all embedders.
| funcref_ptr, | ||
| crate::TRAP_INDIRECT_CALL_TO_NULL, | ||
| ); | ||
| if features.gc() { |
There was a problem hiding this comment.
Should this be features.function_references() || features.gc()? Or just features.function_references()?
Added an item to #9351 I think much of this is equivalent to making |
2 participants
When Wasm GC is enabled, the
[return_]call_indirectinstructions must do full subtyping checks, rather than simple strict equality type checks.This adds an additional branch and slow path to indirect calls, so we only emit code for this check when Wasm GC is enabled, even though it would otherwise be correct to always emit it (because the
is_subtypecheck would always fail for non-equal types, since there is no subtyping before Wasm GC).