Currently, do-these-references-alias queries for Wasm global variable
accesses are handled incorrecty. We fail to identify the case where both
references are indirect (that is, imported) as possibly-aliasing. This can
lead to incorrect code generation in some pretty simple cases involving
globals, when compiling Wasm via IonMonkey.
This commit fixes that. It also adds clarifying comments to
MWasmLoadGlobalVar::congruentTo and MWasmLoadGlobalVar::valueHash pertaining
to equivalance-of-loaded-values assessments.
--HG--
extra : rebase_source : 3f77fa1fd0085ab1922b8eaf7cb2d9891bc6e390
This augments the Ref type patch by making the subtype test perform automatic
upcasts to prefixes. The prefixes are still quite strict; corresponding Ref
types must name the same underlying type and corresponding fields must have the
same mutability.
--HG--
extra : rebase_source : 43cc552e77f9e3f5d7f7b2fa761d956c9c61f149
extra : intermediate-source : bb1d37aa16dd0dbdf21c80e34156026693b898cf
extra : source : 2c8c0301cc33ca0af490629a999f2d2dd854d72f
The StructType and AstStructType machinery must retain the information about
field mutability (to be used by subsequent patches).
For StructType, I opted to create a StructField structure that holds the
information per field. This works well except when we (occasionally, not in
this patch) need an array of ValTypes for some existing functionality.
For AstStructType, I opted to keep the array of mutability flags separate from
the arrays of names and field types, because this was simplest.
In either case, we could do it the other way.
--HG--
extra : rebase_source : a99a2ff5619441f4d0d428fdf1890adef892d5aa
extra : source : 78d954331af90f6f81bd86595beef2c15952510f
We generalize ExprType and StackType in the same way as ValType, in
order to reduce the scope for error. (Intermediate solutions that
avoided this turned out to be too error-prone.) ExprType, StackType,
and ValType now share a representation of a TypeCode + reference type
index, called PackedTypeCode, but don't otherwise share much code -
ExprType is going away soon and StackType will change.
We then generalize many of the Ast nodes so that we can represent the
new types available in the binary and textual formats. This is
wrenching in the same way that generalizing ValType and ExprType was.
Finally we provide parsing, resolution, printing, and validation of
(ref T) where T is some structure type. This code should be general
enough to later expand it to array types.
The type calculus here is that (ref n) == (ref m) if n == m, ie, these
are nominally equivalent; the only new subtype relationships are that
(ref n) <: (ref n) and (ref n) <: anyref. If the subtyping of anyref
were to go away there's a small amount of work that would have to be
done to handle the polymorphism of ref.is_null.
--HG--
extra : rebase_source : 7a1a01d1f5624baeb29383a9ae6a5bdf03411181
extra : intermediate-source : dc8f0270e0e3932ba661a57496401d00903c9ba2
extra : source : 3c5da122b7034dae69d16ca9e577afb93cf7b2c1
As a tweak the wasm CG has decided to allow the special case where an i64 global is
created from JS with the default zero value, while we're waiting for BigInt and
more general i64 support. This amounts to removing the error we would otherwise
signal in this case.
--HG--
extra : rebase_source : 264c1907e0787f067cc954c98726733227e79a78
As a tweak the wasm CG has decided to allow the special case where an i64 global is
created from JS with the default zero value, while we're waiting for BigInt and
more general i64 support. This amounts to removing the error we would otherwise
signal in this case.
--HG--
extra : rebase_source : 680e25f094ddf6339e2eacc7a7da2b197d5d1849
This only recognizes the new syntax and adds a minimal amount of testing for that.
A subsequent patch will do a massive renaming in the wasm module to change
CurrentMemory to MemSize and GrowMemory to MemGrow, and change all test cases.
A final patch will remove support for the old syntax.
