Closed Bug 1706124 Opened 2 years ago Closed 2 years ago

Support WebAssembly extended constant expressions proposal

Categories

(Core :: JavaScript: WebAssembly, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox90 --- fixed

People

(Reporter: rhunt, Assigned: rhunt)

References

Details

Attachments

(7 files)

Add support for the WebAssembly extended constant expressions proposal [1].

[1] https://github.com/WebAssembly/extended-const

I'll take this as part of the work to support the GC proposal.

Assignee: nobody → rhunt
Priority: -- → P3

Non-essential clean-up to split off functionality for binary parsing out
of validation. This is useful for a future interpreter loop which runs
in a non-validation context, and would only like to deal with a
Decoder.

Non-essential clean up to prepare Decoder for being used in an
interpreter loop.

Depends on D112654

Non-essential clean up of OpIter to prepare for being used to decode
and validate constant expressions, in addition to function bodies.

Depends on D112655

Drive-by fix to drop preference for reftypes from StaticPrefList.yaml. This is no
longer used now that the reference types feature gating code is gone.

Depends on D112656

This commit rewrites InitExpr so that it supports multiple instructions. This
unlocks the ability to implement the extended-constants proposal, along with
rtt.canon/rtt.sub initializers for the GC proposal.

An InitExpr now contains either a literal value for simple expressions, or
a vector of bytecode to be evaluated later. Decoding an InitExpr now uses OpIter
to iterate over instructions and validate the results. OpIter is tweaked to
support alternate validation rules to support the additional restrictions that
initializer expressions have, such as global.get only working on immutable
imported globals. The exception is ref.func, which has special rules that I
defer to its own commit to follow.

An interpreter loop is added to evaluate the bytecode and yield a wasm::Val.
The loop uses a Decoder directly and assumes that the bytecode has been validated
already. The interpreter is not fast, and I assume it doesn't need to be at
this time.

Much code that assumed InitExp was POD had to be updated. Notably, GlobalDesc's
fields have been reorganized to remove the double nested union to make it
sane to store allocated data in it.

I initially intended for the expanded constant expression support to have
it's own header and implementation file (WasmInitExpr.h, WasmInitExpr.cpp).
I then discovered that InitExpr is involved with a challenging include loop
with WasmTypes.h and settled with a just giving it it's own implementation
file. This is unusual for wasm/ some I'm open to discussions. In the
longer term, I would like to break up WasmTypes.h.

Depends on D112657

ref.func validates specially.

  • In the 'module environment', any function may be the target and using a function
    as a target marks it as available to be targeted in the code section.
  • The the code section, only functions used in the 'module environment' may
    be targeted.

Additionally, any target of ref.func becomes an 'exported function' and will get
a thunk generated for it. The logic for this existed in ModuleGenerator, which
would traverse over all relevant metadata in ModuleEnvironment to find which
functions may be exported. This no longer is trivial, as an InitExpr may
now contain a ref.func instruction encoded in its bytecode vector, instead
of the tagged union that InitExpr was before.

To satisfy all of these requirements, this patch reworks this code.

  • A FuncFlags enum is added to FuncDesc for each function definition.
  • FuncFlags describes whether a func is exported, eager, and can be
    targetted by ref.func.
  • Decoding the ModuleEnvironment now updates the flags of functions as
    it goes.
  • OpIter uses the validation mode to determine whether to check the
    func flags for a ref.func, or not.
  • ConstExpr::decodeAndValidate updates the flags of functions as it goes.
  • ModuleGenerator no longer computes the exported function information
    itself, and relies on function flags.
  • AsmJS writes to function flags for exported functions specially, as
    it previously relied on sharing the exported function code in
    ModuleGenerator that has moved to decoding/validation.

Depends on D112658

This commit implements the extended-constants proposal.

  • A new feature flag and pref are added.
  • Basic tests are added.

Depends on D112659

Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/autoland/rev/adad50695cd8
wasm: Move Encoder/Decoder to their own file. r=lth
https://hg.mozilla.org/integration/autoland/rev/7587b3d1e1b8
wasm: Organize Decoder for adding more methods. r=lth
https://hg.mozilla.org/integration/autoland/rev/8a6902f9eb84
wasm: Organize OpIter. r=lth
https://hg.mozilla.org/integration/autoland/rev/d1359ed1952b
wasm: Remove unused reftypes preference. r=lth
https://hg.mozilla.org/integration/autoland/rev/20a0e3ebaa85
wasm: Rewrite InitExpr to support multiple instructions. r=lth
https://hg.mozilla.org/integration/autoland/rev/63b4308bedf6
wasm: Clean up ref.func/exported function logic in InitExpr. r=lth
https://hg.mozilla.org/integration/autoland/rev/f595f8c9a333
wasm: Implement the extended-const proposal. r=lth
Regressions: 1710576
You need to log in before you can comment on or make changes to this bug.