Add new compound Signature, Struct and Array types

[dcodeIO]

Introduces TypeInfo as a common descriptor to represent compound Signature, Struct and Array types in addition to the existing Tuple types and refactors internal maps to use TypeInfo as their key.

[dcodeIO]

Some of my thoughts about the changes made to provide some context.

[tlively]

Looking good so far!

[tlively]

I think this should be the last round of comments :)

[dcodeIO]

Since Types are small anyway we are either pushing its uintptr_t id or an equally sized reference, so that's mostly style, right?

[jayphelps]

Side note: binaryen master is still in a weird state where we've changed anyref to externref, but the other reference types changes haven't yet been applied; in this case, there is no longer any subtyping relationship, so I assume this method needs to be refactored out as part of removing nullref, adding an immediate type tag to ref.null, etc.

Apologies if this causes issues for folks, I only had spare cycles to do the initial work.

[dcodeIO]

Thanks for the reminder. Plan forward might be:

1. Complete this PR so we have a foundation for compound types
2. Remove nullref, add eqref, i31ref and the new anyref alongside initial handling of the new compound types
3. Think about RTTs
4. Update ref.null and ref.is_null alongside adding the new GC instructions

[jayphelps]

That seems good to me. Apologies if it was already top of mind 🤡

[tlively]

cc @aheejin, who I think was planning to make some changes to reflect the current state of reference types. It would be good to coordinate with her on who is going to make what changes.

On topic here, I think it would be best to keep passing the types directly here. The extra indirection of passing a reference (which means the values must be in memory rather than in registers) is unnecessary. The only reason we use const Type& for operator== and friends is that those are the standard kinds of types used for those operator overloads.

[aheejin]

I have a half-baked (or, more precisely, quarter-baked) patch for bringing reference types proposal up to date in my local machine, which I started some weeks ago and didn't get around to finish. I'm now trying to pick up the patch.. Do you need that changes for GC? I don't want to block you from proceeding to wait for my patch, but at the same time, I think it is good to add that reference type patch separately from GC and make sure all existing (and to-be-updated) tests the fuzzer pass with reference types proposal, because currently the fuzzer is testing reference type instructions already.

I was away for most of the last week. I was gonna make this change this week, but please let me know if your plan is blocked by this or interfere with this schedule, in which case we can change the plan. I wasn't able to take a look at this patch yet, but I think I'll soon.

[tlively]

The GC proposal restores anyref and nullref, so all we really need to do right now is add an externref type. But some current uses of anyref might need to use externref instead. @aheejin, you'll have a better idea than me whether it's better to rename the current anyref to externref then add a new anyref as part of the GC work or to just add a new externref to what we already have.

[aheejin]

I'm confused.

• Does the GC proposal really restore nullref? After the recent reference type changes, every reference type can be nullified, or in other words, have a null value. Why would we need to restore a separate nullref type? I think what you quoted is just not up-to-date, no?
• I think we should add anyref; anyref and externref seem to be two separate types. anyref is a supertype of all reftypes while externref is not.

[dcodeIO]

Iiuc there is no nullref anymore.

[tlively]

Aha, I've been looking at the wrong GC document. Thanks for the clarification, @dcodeIO!

[tlively]

Looks good to me with those small changes. Let me know if you agree that it's ready to land :)

[dcodeIO]

This should be consistent in itself even though it doesn't yet address recursive types (probably either mutable compound types one can populate before canonicalization or type pointers) or RTTs (probably a new kind of compound type), but yeah, should be good to merge as a basis for further work :)

Invocations so far:
   FuzzExec: 1125
   CompareVMs: 301
   CheckDeterminism: 78
   Wasm2JS: 294
   Asyncify: 299