Right now a JS interop callback works like this:
* Each wasm module that gets instantiated will be given it's module
instance (JS calls Dart to set it) via `setThisModule`
* When Dart code calls JS and gives it a callback to invoke, it gave it
this module instance. It will also make the callback wasm function
weakly exported.
* The JS trampoline code, when invoked, would then call the weakly
exported wasm function from the module instance.
We simplify this now by making the Dart code simply give the wasm
function reference to JS, then JS can later on invoke it. No need to
weakly export a function and call back via
`module.exports.<weaklyExportedCallback>`
To ensure binaryen is aware that the wasm function may be called from
JS, we annotate it via the `(@binaryen.js.called)` annotation.
Change-Id: I828dd0cf8d3b36db338792c4e277a4bb94c76faf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/511080
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Binaryen introduced `binaryen.inline` which allows us to tell it
inlining hints now, including "never inline" hint (see [0])
This allows us to remove the ugly mangling of wasm function names with
`<noInline>` postfix.
We also now pass `--strip-toolchain-annotations`: The annotations
occupy size in the wasm binary and wasm runtimes ignore them (they are
for `wams-opt` only).
Except for IR tests: Here we want to see the annotations, so we keep
them there.
We also rename the package:wasm_builder classes to clearly indicate
those are binaryen specific sections.
We also make the ir_test.dart put it's options first, allowing the IR
tests to override options if needed.
[0] https://github.com/WebAssembly/binaryen/commit/3c25487214600a9
Change-Id: I96688bfaeba403a39cd5e7376f8d2889bcbae030
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510000
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
The change in [0] increased the language version of pkg/dart2wasm. That
in return changes how the package is formatted by the autoformatter.
This CL runs now the formatter to re-format the code. Unfortunately this
makes blame lists worse. But not doing it will make us have to disable
auto-formatting before saving files which is very annoying.
[0] https://dart-review.googlesource.com/c/sdk/+/487944
Change-Id: Ie3cbdc58bbd7f5aba187470554b7c958719fa795
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496940
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
If a function doesn't have an effect we can now mark it via
`@pragma('wasm:pure-function')`. We'll then emit this as metadata
in the `binaryen.remove.if.unused` custom section.
This allows `wasm-opt` to remove calls to such functions if the result
of the call isn't used.
For now we mark a few string functions as pure.
Closes https://github.com/dart-lang/sdk/issues/62665
Change-Id: I8d38fb5894fd98248dc4d648d99c8cdcddc271a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481802
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Changes to IR printing implementation:
* Emit omitted `<...>` marker to make difference between function
without body and function with omitted body clear.
* Extend omtting capability to globals, types and tables
* Extend filtering capability to globals, types, tables
* Better table names: Try to use import or export names if available.
* Option to print globals & types always multiline
* Option to scrub absolute file uris (which aren't stable across machines)
Changes to IR binary / text:
* Extend binary parsing of element section to support imported tables
* Add printing of those (which shows how imported tables are patched)
(The patching of importing tables is used in deferred modules)
Changes to IR test framework:
* Allow more filters (see above) in the test files.
* Allow tests to use helper libraries (containing `.h.` in their name)
without them being considered tests themselves.
* Allow using deferred loading in tests and write expectation files for
main & deferred modules as wat files.
Other things:
* Share more code between `pkg/dart2wasm/bin/wasm2dart.dart` and
`pkg/dart2wasm/test/ir_test.dart`
* Add baseline test for deferred loading using tear off constants
Change-Id: Ica6666f23f5aa6fb2174f414c9082039940f8dc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456460
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
In order to test generated code for a function one can
* place a dart file in `pkg/dart2wasm/tets/ir_tests`
* annotate functions that shouldn't be inlined
* describe which functions we want to dump in the expectation file
* generate an expectation file.
This will allow generating renatively small expectation files for only
functions we care about and types/globals/... those functions need.
Change-Id: Ic7b6b6dece16ab453202aa2c4f9412de2fc251ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454840
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This adds support for printing module IR as text format.
For convenience we add a `pkg/dart2wasm/bin/wami.dart` that
produces very similar output to V8's `wami`.
The goal is to use this to write size/perf optimization tests
by dumping IR into expectation files (will add this
infrastructure in a future CL)
Issue https://github.com/dart-lang/sdk/issues/60928
Change-Id: I42d19c2b8c6242f55693d6ed5d844a5c1ecb1f39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454600
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This adds a wasm binary reader that produces an `ir.Module`.
We also make a few changes to existing code
* Represent the import section with an `ir.Imports` object (similar to
`ir.Exports`, `ir.Functions`, ...)
* We make a bunch of data structures allocatable in uninitialized state
(the fields being usually uninitialized `late final` fields) where the
deserializer can create those objects and then fill in details later.
=> This comes partly due to the way wasm binaries are structured
themselves: The "data count" section comes first so a reader knows
how many data sections there will be, then the "code section" can
refer to those data sections. Then afterwards the actual "data
segment" comes that fills in the data of the section.
* We make names consistently optional: Wasm objects don't have to have
names, so the names should be optional, so we make them `String?`. We
also make them non-final as that's consistent with other names.
* We make the `ir.Types`, `ir.Functions`, ... objects have `operator[]`
and the index used is the same index used e.g. in wasm instructions.
* We make static constants for section ids and custom section names.
Issue https://github.com/dart-lang/sdk/issues/60928
Change-Id: I5394d6b82cf4dc68d24cea1dee66c5b33eb2f60f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452144
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
We have a relatively clean separation between the data structures
representing a wasm module (e.g. `Module`) and the classes used to
build such a module (e.g. `ModuleBuilder`)
Though with deferred loading changes the core IR data structures started
to get a `ModuleBuilder get enclosingModule` getter.
This CL makes the IR classes self-contained again.
=> The `enclosingModule` getter will now return a `Module` instead of a
`ModuleBuilder`
=> The `*Builder` classes that need a `ModuleBuilder` can store that
themselves but only pass up `Module` to IR classes.
Since the IR data structures are cyclic (the `Module` has various parts
that refer back to it via `enclosingModule`), we allow the `Module`
object to be constructed in an uninitialized state and initialize it
after building the module is done.
Issue https://github.com/dart-lang/sdk/issues/60928
Change-Id: I5fddd6ca43b662a6e6c328230e91b1bc75332deb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/451720
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Local names for function value parameters and for "precise this", return
values are generated, state indices in `async` and `sync*` functions are
generated.
We can generate names for more locals as needed.
Change-Id: Ie919f030f0bfae8adbca90408509dd04a7414278
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/419200
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Add map-like entity that handles importing/exporting wasm entities as they are needed across modules.
Expands the Exportable interface to support this functionality since these are the entities that can be shared across modules.
Change-Id: Iefc9320af48c36ea039355a573943c9dbcc4ed8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383222
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Add support for a StaticTable which holds references to known functions that need to be called across modules. For calls that target the DispatchTable we will still go through there if possible. But for any functions not referenced in that table (including any compiler generated functions) we add a separate static table.
Also adds import/export support to both the DispatchTable and the StaticTable. The table will always be defined in the main module and imported into subsequent modules.
Change-Id: Iedc683d1ecfe721393900913826010cdd9b2c3c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381323
Reviewed-by: Martin Kustermann <kustermann@google.com>
This implements generating source maps for the generated Wasm files.
Copying dart2js's command line interface, a source map file with the
name `<program name>.wasm.map` is generated unless `--no-source-maps` is
passed.
When a source map is generated, the generated .wasm file gets a new
section `sourceMappingURL` with the contents `<program name>.wasm.map`.
This section seems to be undocumented, but Chrome and binaryen recognize
it as the URI to the source map file. Chrome is then loads it
automatically in the DevTools.
## Implementation
- `wasm_builder` package is updated with the new `source_map` library,
which describes the source mapping entries.
- `wasm_builder`'s `InstructionsBuilder` is updated with the new public
members:
- `startSourceMapping`: starts mapping the instructions generated to
the given source code.
- `stopSourceMapping`: stops mapping the instructions generated to a
source code. These instructions won't have a mapping in the source
map.
- `CodeGenerator` sets the source file URI and location in the file
when:
- Starting compiling a new member
- Compiling an expression and statement
Change-Id: Ic8f723f7a154402c0d34710689db57d640b83b86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370500
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This CL mostly just moves code around. There are three broad changes in this CL:
1) Reify the builder / built pattern that exists implicitly in the existing code. Builders now live in `src/builder`, while the built ir lives in `src/ir`.
2) Reify the module subsections.
3) `pkg/dart2wasm` has been updated to use the new API.
There is only one minor logic change in the entire CL, we now defer serialization of a module until the bytes are actually required, as opposed to serializing eagerly.
This change is designed to make the wasm_builder more robust. By clearly delineating which parts of the AST are mutable and which parts are immutable, then it should make it easier for users of the wasm_builder to avoid undefined behavior, i.e. holding on to something that can change.
Change-Id: I676107b867aa74fabf413108673e170126bdb5c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316280
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Martin Kustermann