Make imported functions inexact

[kripken]

Defined functions remain exact, but imported ones are inexact.

This is a step along the recent Custom Descriptors spec changes.

• New RefFunc::finalize and Literal::makeFunc variants get the module, and look up
  the type there.
• New Builder::makeRefFunc variant gets a Type and applies it. The HeapType
  variant does a lookup on the module (so the Type one is more efficient/applicable
  if the IR is not fully built yet).
• ReFinalize now updates RefFunc types (following the pattern of a few other places).
• C and JS APIs now assume RefFuncs are created after imported functions (so we can
  look up the type of the import; see changelog, this seems the least-annoying way to
  update here, avoiding new APIs, and less breakage for users - hopefully none, all our
  tests here pass as is).
• wasm-split adds a cast when a function becomes an inexact import.
• Fix GUFA to handle inexact function literals.
• Update types in passes and fuzzer as needed.

[kripken]

Fuzzer noticed that we didn't type imported ref.funcs correctly. Last two (non-merge) commits fix and test that.

[tlively]

Don't we still want to track that this is a reference to the imported function? It would just have an inexact type.

[kripken]

But without knowing the identity, I think we can misoptimize? Imagine we have equality for a second, then ref.func a == ref.func a is definitely 1, but ref.func a == ref.func b is not necessarily 0 (can have duplicate imports).

[tlively]

But functions references cannot be compared for equality, so there is nothing to misoptimize, unless I'm missing something.

[kripken]

I did say "imagine" 😆

But, while we don't have ref.eq on functions in wasm userspace, we do have optimizations that compare functions in other ways. E.g. folding an if with ref.eq arms, or GUFA inferences. I admit I don't see an actual bug atm in our optimizer, but a future one is conceivable.

[tlively]

I can see how optimizations might see that two references are the same and e.g. merge two equivalent if arms or something like that, but I still don't see how we could ever have an optimization that does something unsafe when reasoning that two different function references are different. Can we at least consider changes here in a separate PR?

[tlively]

Yes, agreed. I'm not opposed to being conservative here to be on the safe side. But we should keep the less-conservative status quo in this PR to make sure we're not unexpectedly regressing optimizations due to just the introduction of inexact imported functions.

[kripken]

Keeping the status quo does mean keeping the known cases of invalid optimization we have today, including the new gufa.wast tests here, like

(module
  (type $func (sub (func)))
  (type $sub (sub $func (func)))

  (import "" "" (func $f (type $func)))

  (func $test (export "test") (result i32)
    (ref.test (ref $sub)
      (ref.func $f)
    )
  )
)

We misoptimize that to 0 before the fix, because we think imported function literals are actual concrete functions. Given such an actual function, we don't need exactness to know that it will fail that test.

The fuzzer can find this after this PR - perhaps because of the new testcases? Or perhaps because of the companion fuzzing PR #7963, which should really land as it increases coverage enough to find those recent vulnerabilities. So while I see your point, our options seem to be

• Land this PR as is, fixing the misoptimization but potentially regressing optimizations on imported function references.
• Land this without fixing the misoptimization, which will not regress any opts, and work around it in the fuzzer, maybe not landing Fuzzer: Merge and optimize even with closed world in Two() #7963, maybe marking new tests as non-fuzzable, maybe both.
• Fix the misoptimization otherwise, e.g., GUFA/possible-contents could special case function literals in various places.

[tlively]

What if GUFA has a function literal, but its type isn't exact?

[kripken]

It is still a literal. The code assumes that a literal is an actual identifiable thing, like 42 or the function "foo", and unlike a global "bar" (whose value we don't know).

We could special-case the code to make it treat an inexact funcref as "a literal, but not really; more like a global." But that won't work once we have exact function imports - the same problem would happen with exact ones.

[tlively]

I don't see the problem. Once we have exact imports, then the Literal for the imported function would have an exact type iff the import is exact. GUFA would then look at the literal type to see whether casts would succeed or fail, for example. The changes to support inexact function literals are already in this PR.

[tlively]

Is this still TODO?

[kripken]

Oops, just some old text. These casts become exact. Cleaned up now.

[tlively]

Let's add some exact casts to the test to show that they work as expected. I don't think the test currently demonstrates that.

[kripken]

Sure, added.

[tlively]

The comment suggests we should have been able to optimize this.

[kripken]

Good point, I think we need to look at finality in GUFA somehow. I added a TODO.

[tlively]

I suspect this will be fixed by using a non-exact Literal for references to function imports.