One complication is that the super-fast path, which inlines any boxing into JS code that calls wasm by means of the usual MCallOptimize thing, will end up exposing MIRType::RefOrNull to JS. Long-term this may be right, but short-term probably not, so for initial work we should probably keep the guard in place here and not do this path for reftypes (perhaps unless we know the inputs are pointers). We should still be able to do a fast path that goes through the optimized stub, where we control the frames and value flow more tightly.
Bug 1532556 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
One complication is that the super-fast path, which inlines any boxing into JS code that calls wasm by means of the usual MCallOptimize thing, will end up exposing MIRType::RefOrNull to JS. Long-term this may be right, but short-term probably not, so for initial work we should probably keep the guard in place here and not do this path for reftypes (perhaps unless we know the inputs are pointers). We should still be able to do a fast path that goes through the optimized stub, where we control the frames and value flow more tightly. [Update: The patches pending on bug 1581572 do indeed expose RefOrNull to JS on the path from JS into wasm, though not in any other situations.]