-
Notifications
You must be signed in to change notification settings - Fork 785
Update the binary format for exact heap types #7502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Revert the following PRs that introduced exactness on HeapType: - #7446 - #7444 - #7432 - #7412 - #7396 Keep only the changes to wasm-type-printing.cpp to fix the assertions that subclasses of TypeNameGeneratorBase correctly override getNames. Although putting exactness on heap types makes the most sense in the Custom Descriptors spec, it is not a great fit for how HeapType is used in Binaryen. In almost all cases, HeapType is used to represent heap type definitions rather than the dynamic types of values. Letting HeapType represent exact heap types is not useful in those cases and opens up a new class of possible bugs. To avoid these bugs, we had been introducing a new HeapTypeDef type to represent heap type definitions, but nearly all uses of HeapType would have had to have been replaced with HeapTypeDef. Rather than introduce HeapTypeDef as a third type alongside Type and HeapType, it will be simpler to continue using HeapType to represent heap type definitions and Type to represent the dynamic types of values, including their exactness. While exactness will syntactically be part of the heap type, it will be part of the `Type` in Binaryen IR. A follow-on PR will restore the original work on exact references, and PRs following that one will update the encoding, parsing, and printing of exact references to match the current spec.
In preparation for disallowing inexact references to abstract heap types, which are no longer allowed by the Custom Descriptors proposal.
Disallow exact references to abstract heap types and update subtyping to match the current proposed semantics.
Since the Type representation only needs to include a bit for sharedness for basic heap types and only needs to include a bit for exactness for non-basic heap types, they can use the same bit. Using fewer bits in the Type representation is beneficial because it reduces the minimum alignment of HeapTypeInfos required to avoid trampling the reserved bits.
Since exactness is syntactically part of the heap type, it introduces a new level of parentheses inside the reference type. Update type printing and the text parser accordingly.
Although we now store exactness on `Type` instead of `HeapType`, the binary format still encodes exactness as part of the heap type. Update the binary parser to read exactness wherever a heap type (but not just a type index) is expected and update the binary writer similarly.
@@ -1378,7 +1375,7 @@ class WasmBinaryWriter { | |||
|
|||
// Writes an arbitrary heap type, which may be indexed or one of the | |||
// basic types like funcref. | |||
void writeHeapType(HeapType type); | |||
void writeHeapType(HeapType type, Exactness exact); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a default of inexact to save typing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this API is local to the binary writer, I think it's best to be explicit and avoid future mistakes.
Although we now store exactness on
Type
instead ofHeapType
, thebinary format still encodes exactness as part of the heap type. Update
the binary parser to read exactness wherever a heap type (but not just a
type index) is expected and update the binary writer similarly.