[WebAssembly][Clang] Add intrinsics to make and test for an externref sentinel

[hoodmane]

#139580 adds the ability to test whether an externref is null or not. This can
be used for in-band error signalling, but it can lead to trouble because some
JavaScript functions care about the difference between null and undefined, and
if we use null to signal errors we can't handle a real null value. There are
several possible solutions:

1. Change my functions that return an __externref_t to __externref_t f(int *status, <other args>); (This doesn't require any change to clang.)
2. Somehow let clang deal with functions with multiple return values and give it
   a pair of return values an externref and a status i32
3. Similarly to 2, make the return value a single wasm-gc struct that's a pair
4. Use a struct with no fields as a sentinel

This fourth case could look like:

  if (error_condition) {
     return __builtin_wasm_ref_sentinel_extern();
  }

and then check like:

  __externref_t res = some_func();
  if (__builtin_wasm_ref_is_sentinel_extern(res)) {
     // handle the error
  }
  // Otherwise it represents an actual JS value.

We would have a type like

(type $sentinel (struct)) ;; 0x5f, 0x00

Then __builtin_wasm_ref_sentinel_extern() would translate to:

    struct.new $sentinel ;; 0xfb, 0x00, <type index of $sentinel>
    extern.convert_any   ;; 0xfb, 27

and __builtin_wasm_ref_is_sentinel_extern() would translate to:

    any.convert_extern ;; 0xfb, 26
    ref.test $sentinel ;; 0xfb, 20, <type index of $sentinel>

If we needed to, we could make a second one-value type with:

(type $sentinel1 (struct (ref null noextern))) 

and similarly by adding more (ref null noextern) fields we could make as many distinct
struct-based singleton "sentinel" types as we want.

cc @sbc100 @tlively @pmatos

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Hood Chatham (hoodmane)

#139580 adds the ability to test whether an `externref` is null or not. This can be used for in-band error signalling, but it can lead to trouble because some JavaScript functions care about the difference between null and undefined, and if we use null to signal errors we can't handle a real null value. There are several possible solutions: 1. Change my functions that return an `__externref_t` to `__externref_t f(int *status, <other args>);` (This doesn't require any change to clang.) 2. Somehow let clang deal with functions with multiple return values and give it a pair of return values an `externref` and a status `i32` 3. Similarly to 2, make the return value a single wasm-gc struct that's a pair 4. Use a struct with no fields as a sentinel

This fourth case could look like:

  if (error_condition) {
     return __builtin_wasm_ref_sentinel_extern();
  }

and then check like:

  __externref_t res = some_func();
  if (__builtin_wasm_ref_is_sentinel_extern(res)) {
     // handle the error
  }
  // Otherwise it represents an actual JS value.

We would have a type like

(type $sentinel (struct)) ;; 0x5f, 0x00

Then __builtin_wasm_ref_sentinel_extern() would translate to:

    struct.new $sentinel ;; 0xfb, 0x00, <type index of $sentinel>
    extern.convert_any   ;; 0xfb, 27

and __builtin_wasm_ref_is_sentinel_extern() would translate to:

    any.convert_extern ;; 0xfb, 26
    ref.test $sentinel ;; 0xfb, 20, <type index of $sentinel>

If we needed to, we could make a second one-value type with:

(type $sentinel1 (struct (ref null noextern))) 

and similarly by adding more (ref null noextern) fields we could make as many distinct
struct-based singleton "sentinel" types as we want.

cc @sbc100 @tlively @pmatos

[sbc100]

Does __builtin_wasm_ref_is_sentinel_extern need to be defined by llvm? Couldn't you write that in assembly or wat (in user code?

[dschuff]

I think a more straightforward way to do that would be just to import the undefined value from JS. References to undefined can be freely passed into and out of WebAssembly. (i.e. in spec-ese, you can call ToWebAssemblyValue on undefined and you get a non-null reference to it that behaves the same as any other reference. So you could e.g. have an immutable imported global ref that points to JS undefined and compare other externrefs against it.

LLVM currently has no support for the gc type system (only for reference types). Adding that would be quite nontrivial.

[hoodmane]

Couldn't you write that in assembly

Well we'd need to add assembly support for these webassembly instructions, but that is probably easier.

Import the undefined value

Well this has two problems:

1. We can't use undefined to signal an error because sometimes the result of a JavaScript function is actually supposed to be undefined but there is no error.
2. As far as I can tell, there is no way from within webassembly to check if a value is equal to undefined. My assumption is that calling out to JavaScript to do an equality test is very expensive compared to an instruction like ref.test. If this performance assumption is not correct, then there would be no reason to do this.

LLVM currently has no support for the gc type system (only for reference types). Adding that would be quite nontrivial.

My thought was that if I immediately cast the wasm-gc value to externref with extern.convert_any then that would allow us to use gc types without having to teach LLVM about gc types in any systematic way.

[dschuff]

Well this has two problems:

1. We can't use undefined to signal an error because sometimes the result of a JavaScript function is actually supposed to be undefined but there is no error.

Isn't the same true for null though? Use of both null and undefined ultimately just comes back to conventions. Any JS function can return null, undefined, or something else, and any JS caller has to be able to handle any of those, or decide not to. The same is true for wasm callers. I think you as the user just have to figure out what kind of convention you want in your C++ and JS code, and the job of the toolchain and runtime is to give you the tools.

2. As far as I can tell, there is no way from within webassembly to check if a value is equal to undefined. My assumption is that calling out to JavaScript to do an equality test is very expensive compared to an instruction like ref.test. If this performance assumption is not correct, then there would be no reason to do this.

Ah right, externrefs are not eqrefs. Probably a call to JS is more expensive than a ref.test

LLVM currently has no support for the gc type system (only for reference types). Adding that would be quite nontrivial.

My thought was that if I immediately cast the wasm-gc value to externref with extern.convert_any then that would allow us to use gc types without having to teach LLVM about gc types in any systematic way.

If you want to use a type-based sentinel scheme rather than a value-based one, then you need to be able to encode that type as an indexed type in the type section, and I think that would get you a lot of the way down the rabbit hole. To be fair, we are already partway down it because LLVM knows how to parse the type section just enough to skip over it. I don't know, maybe it wouldn't be that bad, you'd have to think it through.
Actually the struct-sentinel scheme has another problem: how do you return values of that type from JS to wasm? You'd have to create one in wasm and pass it back out as an opaque value to JS, and then return it from your JS code to indicate errors. But that seems like just as much work as implementing some other convention such as ensuring that you never return undefined into wasm, or using outparams, or throwing (either way you have to audit all the interoperation code).

[hoodmane]

I think you as the user just have to figure out what kind of convention you want in your C++ and JS code, and the job of the toolchain and runtime is to give you the tools.

I decided a while ago that it should be acceptable to not handle null since I figured it was uncommonly used. Unfortunately, I have users complaining that they want to call JavaScript functions that handle null and undefined differently. Thus, I need a third error value. An empty struct seems great for this.

How do you return values of that type from JS to wasm? You'd have to create one in wasm and pass it back out as an opaque value to JS, and then return it from your JS code to indicate errors. But that seems like just as much work as implementing some other convention such as ensuring that you never return undefined into wasm, or using outparams, or throwing (either way you have to audit all the interoperation code).

I use macros like the following everywhere:

#define EM_JS_VAL(ret, func_name, args, body...)                               \
  EM_JS_MACROS(ret WARN_UNUSED, func_name, args, {                             \
    try    /* intentionally no braces, body already has them */                \
      body /* <== body of func */                                              \
    catch (e) {                                                                \
        LOG_EM_JS_ERROR(func_name, e);                                         \
        Module.handle_js_error(e);                                             \
        return null;                                                           \
    }                                                                          \
    errNoRet();                                                                \
  })

And the callee has FAIL_IF_JS_NULL. So adding an exported function that returns this sort of sentinel and setting it to Module.js_error_sentinel and then returning that instead of null would be only require a change in this one spot in the code. Currently I have to use return nullToUndefined(result); everywhere and I could delete those calls to nullToUndefined() as well. Basically no restructuring would have to happen on the C side.
https://github.com/pyodide/pyodide/blob/main/src/core/error_handling.h#L113-L123

I think the main blocker is that iOS Safari has broken wasm-gc support so I would have to wait for apple to fix that.

Using an outparam is probably the best way to go but it will be a huge refactor to all of my code. Intrinsics like this would let me add support for null without hardly any changes to my code. So I think there would be some value here.