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: I6953fe0d6a824b2b79a26bbadb0bb977cec70b7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/490821
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
With `loadDeferredModule` there was no easy way for the embedder to batch module loads that were part of the same load ID. The loop happened within the wasm runtime and so the best the embedder could do was a `setTimeout(f, 0)` and collect the modules before making a request. This can lead to unintended delays though.
Instead we now pass the full list of modules to the embedder's registered loader along with an instantiator function so that the emebedder can start compiling concurrently before all the modules are done loading.
Added a changelog entry since this API is new but might be in use.
Change-Id: I4ae3a9fc28fc726909f63a1dd4ea1d98d5fc3fc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481360
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
To avoid depending on exact ordering binaryen uses in the wasm module,
we start
* enqueue functions/types/... based on sort name instead of index
in wasm module
* only assign increasing ids in `Namer` if we actually want to print
the name
* print functions/types/... in sorted order
for IR tests.
We also update the `pkg/dart2wasm/bin/wasm2wat.dart` tool to be
able to dump wat for multiple wasm modules.
Change-Id: Ifbfc9149a629cf5ceacd95b7cb4892e9de3d4d9c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465341
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@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>
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>
Load ids provide a way to reduce the overhead of deferred loading. By
default deferred loading requires mapping `loadLibrary` calls to a list
of modules. This requires including (1) library uris, (2) prefix names
and (3) module names directly in the main module. With this loading
modules is easier as the loading function gets the exact filename.
Load ids provide an alternative approach where the compiler emits a
separate file mapping a load ID to the module set required for that ID.
An app could store this mapping on the server allowing the frontend to
include only the load ID in its request and have the server figure out
which modules to send back.
Internal serving infra uses module sets like this so this change allows
easier integration into that tooling. Dart2js already supports emitting
this deferred mapping JSON and internal infra is using that today.
Other changes include:
- Run the deferred loading transformer after TFA. This will exclude unused libraries in the resulting deferred loading map. Mark deferred helpers as entry points so that they don't get tree-shaken.
- Some changes to naming conventions of JS helpers.
- Use filename as module name to simplify JS helpers
Change-Id: I5e2f5e374de77c87095d08bfff6534506cb10652
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454240
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This updates the dynamic module compile to emit an extra mjs file containing JS-defined functions and values (i.e. Strings). The runtime then loads this JS module along with the wasm module and links the two.
Change-Id: Iedddf378822f3abd957f0ca9016a9f7883854973
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/422341
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Missing from this implementation:
- Closure/dynamic calls with differing signatures
- Overrides with extra optional parameters
- Records with same shape defined in different dynamic modules
- Avoiding running TFA on dynamic module.
- Recompilation of only updateable functions from main module.
- Persist wasm def types from main module.
Testing is currently done locally via the dynamic_modules package test suite:
dart pkg/dynamic_modules/test/runner/main.dart --runtime=dart2wasm
Immediately after this lands we can introduce a new step to one of the wasm test matrix configurations that runs the above test suite (the VM has a similar configuration).
Change-Id: I3386d84be11b773842d45f4268a62a54c47e352b
Tested: Tested via new tests in dynamic_modules package. Tests run locally but will add to existing config.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397721
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Currently when the .wasm file path passed to run_wasm.js is a relative
path, `Uri.base` becomes something like `file://test.wasm`, which is not
a valid file URI, so it causes crashes in `Uri.toFilePath`.
When the file path is relative add a omit `file://` prefix.
`Uri.base` values before and after:
- Before, relative .wasm path: `file://test.wasm` (invalid)
- Before, absolute .wasm path: `file:///home/user/test.wasm`
- After, relative .wasm path: `test.wasm` (fixed)
- After, absolute .wasm path: `file:///home/user/test.wasm` (same as before)
Change-Id: I0d1c43716e07a9ee926e7feeeab514c2c66bac16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385700
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Adds a mode that puts every library (outside of the SDK) into its own wasm module. Each module is then loaded before the program executes.
This allows us to get better coverage on multi-module logic.
I chose to augment the SDK `_invokeMain` entry point because it allows us to push the user-defined main into a second module ensuring we always have at least 2 modules. The SDK alone is then the main module and all user-code is in deferred modules.
The next step is to make a test configuration for this and decide what frequency to execute it with.
Change-Id: I01bf3a5fee4604a890ef376ebd35113281a36a5c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384404
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Adds a 'enable-deferred-loading' option to dart2wasm.
Also updates the js shells' run_wasm.js script to support upcoming deferred loading. Adds support for the "fetch" API which will be used to get deferred modules. And adds the JS implementation of the deferred loading helper which will gets imported into wasm.
Change-Id: I6f3cd4d83f5c987dc529ef8f34b3b289ab555d89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379900
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This encapsulates the way we compile, instantiate and run and
avoids exposing the compiled module and the instantiated module.
It also allows us to carry state from compilation, instantiation
and running that can be accessed later during execution.
For example an embedder could supply extra
* builtins for compiling that we can store on `CompiledApp`
* imports for instantiation that we can store on `InstantiatedApp`
This extra information may be required later on at runtime,
e.g. when loading deferred modules that need to be compiled
and instantiated the same way as the main module.
An embedder can use this as follows:
const compiledApp = await compileStreaming(fetch(...));
const instantiatedApp = await compiledApp.instantiate({ <extra imports> });
instantiatedApp.invokeMain(...);
We mark the top-level `instantiate` and `invoke` methods as deprecated,
allowing flutter to migrate without manuall engine roll.
Change-Id: Ie0297909c1d2b8f8dc8c12670d5476ad4ff772cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383242
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
To be able to control how dart2wasm-generated modules are compiled, add
a `WebAssembly.compile` and `WebAssmebly.compileStreaming` wrapper to
the generated runtime blob.
These wrappers do js-string built-in detection and enable the built-in
when it's available.
Once the SDK is rolled into engine we will update the engine dart2wasm
module loader to use `compileStreaming` from the runtime blob, in
https://github.com/flutter/engine/pull/51488.
This will allow enabling the built-in without duplicating the feature
detection and compilation code in the engine.
Change-Id: Icb939f16a2b0ae1d348ec5a814371e9ffde4fd68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381581
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
* We make the test runner use the same runner script as golem uses
* We make the runner script work for different JS shells
=> The runner script encapsulates how to invoke different JS shells, the
commandline format, environment variables, ...
=> Golem can then continue to use same runner script, but also with new
shells
Change-Id: Iad63fe6c0563cfeac28cbfb25eb41ee1b7c13f3a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365740
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
By initializing `location.href` in the commandline JS runners we allow
programs running in D8 to use `Uri.base` (which depends on
`location.href`).
That in return will allow running some Dart programs in D8 that would
otherwise not run (e.g. code using `package:test/test.dart` - which uses
`Uri.base`)
TEST=tests/web/wasm/location_href_test.dart
Change-Id: Ie219f8d9ece3b92f2442200539557f116d2c84ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363700
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
JSC only supports `print()` but not `console.log()`.
=> The changes to `printToConsole()` are therefore extended
to check for `console.log()` as well as `print()`.
=> This is extending it to a broader subset of dart2js's print
Change-Id: I7efa697477aa60e473d01716b104fc1526035c67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347283
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Marked as experimental, and only shown when verbose flag is passed:
```
$ dart help compile -v
Compile Dart to various formats.
Usage: dart [vm-options] compile <subcommand> [arguments]
-h, --help Print this usage information.
Available subcommands:
aot-snapshot Compile Dart to an AOT snapshot.
exe Compile Dart to a self-contained executable.
jit-snapshot Compile Dart to a JIT snapshot.
js Compile Dart to JavaScript.
kernel Compile Dart to a kernel snapshot.
wasm Compile Dart to a WebAssembly/WasmGC module (EXPERIMENTAL).
```
Change-Id: I6a0e65d4fbdd7b2782406b8b9969e14036bf0711
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304860
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Michael Thomsen <mit@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Use JS `setTimeout` for events and `queueMicrotask` for micro-tasks.
dart2js event loop implementation is copied in `run_wasm.js` to be able
to use `clearTimeout`, `setInterval`, `clearInterval`, and
`scheduleMicrotask`, which are not not available in d8, and `setTimeout`
in d8 does not wait before calling a callback.
New passing d8 tests:
- co19/LibTest/async/Future/Future.delayed_A01_t02
- co19/LibTest/async/Stream/Stream.periodic_A01_t01
- co19/LibTest/async/Stream/Stream.periodic_all_t01
- co19/LibTest/async/Stream/Stream.periodic_all_t02
- co19/LibTest/async/Stream/timeout_A04_t01
- co19/LibTest/async/StreamController/stream_all_A01_t01
- co19/LibTest/async/StreamController/stream_all_A01_t02
- co19/LibTest/async/StreamController/stream_all_A02_t01
- co19/LibTest/async/StreamController/stream_all_A02_t02
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A01_t01
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A01_t02
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A02_t01
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A02_t02
- co19/LibTest/async/Timer/Timer.periodic_A01_t01
- co19/LibTest/async/Timer/Timer_A01_t01
- co19/LibTest/core/Stopwatch/elapsedTicks_A01_t01
- language/async/call_test
- language/regress/regress21795_test
- lib/async/multiple_timer_test
- lib/async/periodic_timer2_test
- lib/async/periodic_timer3_test
- lib/async/periodic_timer4_test
- lib/async/schedule_microtask3_test
- lib/async/schedule_microtask_test
- lib/async/stream_timeout_test
- lib/async/timer_isActive_test
- lib/async/timer_repeat_test
- lib/async/timer_test
New passing Chrome tests:
- co19/LibTest/async/Stream/timeout_A04_t01
- language/async/call_test
- lib/async/schedule_microtask3_test
Tests below fail because of async* desugaring issues and will be fixed
separately:
- language/async_star/no_cancel2_test
- language/async_star/no_cancel_test
Tests below fail because of an existing issue (#29615):
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A01_t03
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A02_t03
- co19/LibTest/async/StreamController/stream_all_A02_t03
Fixes#51599.
Change-Id: Ib313e99bf3b3cb3bebeddc9e47dc77425ef94481
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305201
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This CL re-implements the async function compilation without using JSPI
or any other platform features.
This implementation is faster than the JSPI-based one in all benchmarks,
in some cases up to 200x (benchmark results at the end). So we remove
the JSPI-based implementation as there's no point in maintaining a much
slower implementation and supporting two implementations at the same
time (which is tricky because these implementations need different
libraries, all scripts need to support two modes etc.) that also
requires experimental platform features.
# Main changes
- A new pass `AwaitTransformer` transforms `await` expressions to
top-level statements in form `var <fresh variable> = await <simple
expr>`, where `<simple expr>` is an expression without `await`.
After this pass all `await` expressions have the simple continuation
of "assign the value of the awaited future to this variable and
continue with the next statement". This simplifies `await`
compilation.
- A new code generator `AsyncCodeGenerator` (inherits from
`CodeGenerator`) compiles `async` functions. The `_YieldFinder` class
is copied from `sync*` code generator but modified to handle `async`
expressions.
- Mentions to the V8 flag `--experimental-wasm-stack-switching` is
removed from all scripts and documents.
# Future work
- Control flow handling in `AsyncCodeGenerator` needs to be implemented
in a similar way in `SyncStarCodeGenerator`. Doing this without
duplicating a lot of code will require some refactoring.
# New passing tests
- co19/Language/Statements/Yield_and_Yield_Each/Yield/execution_async_A05_t01
- co19/Language/Statements/For/Asynchronous_For_in/execution_A02_t02
- language/regress/regress23996_test
- language/sync_star/dcall_type_test
# Benchmarks
Current implementation:
```
AsyncLiveVars.LiveObj1(RunTime): 1586000.0 us.
AsyncLiveVars.LiveObj2(RunTime): 2114000.0 us.
AsyncLiveVars.LiveObj4(RunTime): 1972500.0 us.
AsyncLiveVars.LiveObj8(RunTime): 2212000.0 us.
AsyncLiveVars.LiveObj16(RunTime): 2238000.0 us.
AsyncLiveVars.LiveInt1(RunTime): 2362000.0 us.
AsyncLiveVars.LiveInt4(RunTime): 2470000.0 us.
AsyncLiveVars.LiveObj2Int2(RunTime): 2575000.0 us.
AsyncLiveVars.LiveObj4Int4(RunTime): 2820000.0 us.
Calls.AwaitAsyncCall(RunTimeRaw): 35676.15658362989 ns.
Calls.AwaitAsyncCallClosureTargetPolymorphic(RunTimeRaw): 38934.108527131786 ns.
Calls.AwaitAsyncCallInstanceTargetPolymorphic(RunTimeRaw): 42617.02127659575 ns.
Calls.AwaitFutureCall(RunTimeRaw): 2832.058906825262 ns.
Calls.AwaitFutureCallClosureTargetPolymorphic(RunTimeRaw): 3665.8125915080527 ns.
Calls.AwaitFutureCallInstanceTargetPolymorphic(RunTimeRaw): 4420.449537241076 ns.
Calls.AwaitFutureOrCall(RunTimeRaw): 3692.7621861152143 ns.
Calls.AwaitFutureOrCallClosureTargetPolymorphic(RunTimeRaw): 4625.346901017576 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphic(RunTimeRaw): 4514.6726862302485 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphicManyAwaits(RunTimeRaw): 345172.4137931034 ns.
Calls.AwaitForAsyncStarStreamPolymorphic(RunTimeRaw): 697000.0 ns.
Calls.AwaitForAsyncStarStreamPolymorphicManyYields(RunTimeRaw): 704666.6666666666 ns.
Calls.AwaitForManualStreamPolymorphic(RunTimeRaw): 11010.989010989011 ns.
Calls.SyncCall(RunTimeRaw): 0.40275240996973316 ns.
Calls.SyncCallClosureTarget(RunTimeRaw): 0.3989591156672242 ns.
Calls.SyncCallInstanceTargetPolymorphic(RunTimeRaw): 3.2632549336335526 ns.
Calls.IterableSyncStarIterablePolymorphic(RunTimeRaw): 353.3980582524272 ns.
Calls.IterableManualIterablePolymorphic(RunTimeRaw): 332.1161825726141 ns.
Calls.IterableManualIterablePolymorphicManyYields(RunTimeRaw): 354.28067078552516 ns.
```
New implementation:
```
AsyncLiveVars.LiveObj1(RunTime): 11327.683615819209 us.
AsyncLiveVars.LiveObj2(RunTime): 10923.91304347826 us.
AsyncLiveVars.LiveObj4(RunTime): 10956.284153005465 us.
AsyncLiveVars.LiveObj8(RunTime): 11286.516853932584 us.
AsyncLiveVars.LiveObj16(RunTime): 11445.714285714286 us.
AsyncLiveVars.LiveInt1(RunTime): 11016.483516483517 us.
AsyncLiveVars.LiveInt4(RunTime): 11327.683615819209 us.
AsyncLiveVars.LiveObj2Int2(RunTime): 10918.478260869566 us.
AsyncLiveVars.LiveObj4Int4(RunTime): 10737.967914438503 us.
Calls.AwaitAsyncCall(RunTimeRaw): 1082.2510822510822 ns.
Calls.AwaitAsyncCallClosureTargetPolymorphic(RunTimeRaw): 1056.4124234100993 ns.
Calls.AwaitAsyncCallInstanceTargetPolymorphic(RunTimeRaw): 1134.1726210729273 ns.
Calls.AwaitFutureCall(RunTimeRaw): 865.6509695290858 ns.
Calls.AwaitFutureCallClosureTargetPolymorphic(RunTimeRaw): 841.3967185527977 ns.
Calls.AwaitFutureCallInstanceTargetPolymorphic(RunTimeRaw): 839.066957543212 ns.
Calls.AwaitFutureOrCall(RunTimeRaw): 397.9941096871766 ns.
Calls.AwaitFutureOrCallClosureTargetPolymorphic(RunTimeRaw): 406.17384240454913 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphic(RunTimeRaw): 393.7472929873607 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphicManyAwaits(RunTimeRaw): 1095.0503723171266 ns.
Calls.AwaitForAsyncStarStreamPolymorphic(RunTimeRaw): 6643.426294820717 ns.
Calls.AwaitForAsyncStarStreamPolymorphicManyYields(RunTimeRaw): 7178.750897343863 ns.
Calls.AwaitForManualStreamPolymorphic(RunTimeRaw): 1456.23998835008 ns.
Calls.SyncCall(RunTimeRaw): 0.3919935321067202 ns.
Calls.SyncCallClosureTarget(RunTimeRaw): 0.3906669661780074 ns.
Calls.SyncCallInstanceTargetPolymorphic(RunTimeRaw): 3.1676143112814583 ns.
Calls.IterableSyncStarIterablePolymorphic(RunTimeRaw): 104.4932079414838 ns.
Calls.IterableManualIterablePolymorphic(RunTimeRaw): 104.57516339869281 ns.
Calls.IterableManualIterablePolymorphicManyYields(RunTimeRaw): 116.92487576731949 ns.
```
TEST=ci
CoreLibraryReviewExempt: Added entry-point pragmas.
Change-Id: I02fbd08141f51c00fb37b6fa0304dc25d6afdb71
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301020
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This CL will make it easier to consume `dart2wasm` as a library. Specifically, users can import `package:dart2wasm/dart2wasm.dart`, and call `main` from Dart libraries.
Change-Id: I9f5d5ab539677af2604df9d4b0e1e2d82db7485f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300780
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This is necessary so we can start specializing JS method trampolines. Specializing JS methods will help reduce polymorphic behavior in JS trampolines for JS interop methods.
In the follow on CL we will start injecting specialized JS method trampolines directly into the runtime.
Change-Id: Ib12fb286f54cfb8a64c9f84e238433e8da2eeaa0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/272441
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
In WasmGC MVP, the `array.new_data` instruction will not be a constant
instruction. This means we can't implement the option that places
eager string constants in data segments and reads them using
`array.new_data`. We can still do this for lazy strings.
Also clean out the string function generator (which is dead since we
started using `array.new_data` for lazy strings) and the special case
for the empty string (which is obsolete since we started using
`array.new_fixed` for eager strings).
Change-Id: If28bdf6913ae0cd0f4faf7d87d64cb9412e56bb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/271120
Reviewed-by: Ömer Ağacan <omersa@google.com>
This version contains a number of updates to WasmGC:
- `dataref` is replaced by `structref`.
- `call_ref` now takes a function type immediate, both with the proper
0x14 opcode and the temporary 0x17 opcode.
- Some of the new type test/cast instructions are implemented,
specifically `ref.test`, `ref.cast`, `ref.test null` and
`ref.cast null`. The new `br_on_cast` and `br_on_cast_fail` are not
yet implemented.
Additionally, the `--wasm-gc-js-interop` flag is removed, and interop
is always enabled.
Change-Id: Ibe7a1d9e8800f89096239ff5afa16e80322e01c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/266161
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Make a constant lazy if it involves creating a list that is too long
for the `array.new_fixed` instruction, or, for composite constants, if
one or more of its sub-constants are lazy.
Also read lazy string constants directly from a data segment instead
of writing them to linear memory first.
Change-Id: Iea26460580e6134cd3e26eaaa84cb0dde09016dd
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261402
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Nate Biggs