```
% DART_CONFIGURATION=ReleaseX64 pkg/dart2wasm/tool/compile_benchmark --
CompileFluteComplex.CompileTime.Total(CompileTime): 34.48 s
CompileFluteComplex.CompileTime.Dart2Wasm(CompileTime): 12.74 s
CompileFluteComplex.CompileTime.Wasm2WasmOpt(CompileTime): 21.74 s
CompileFluteComplex.CodeSize.mjs(CodeSize): 11333 bytes
CompileFluteComplex.CodeSize.mjs.gz(CodeSize): 3144 bytes
CompileFluteComplex.CodeSize.wasm(CodeSize): 3462517 bytes
CompileFluteComplex.CodeSize.wasm.gz(CodeSize): 1019112 bytes
CompileFluteComplex.CodeSize.wasm.opt(CodeSize): 1500111 bytes
CompileFluteComplex.CodeSize.wasm.opt.gz(CodeSize): 477204 bytes
CompileFluteComplexMemoryUse.Max(MemoryUse): 574341120 bytes
CompileFluteComplexMemoryUse.Dart2Wasm(MemoryUse): 574341120 bytes
CompileFluteComplexMemoryUse.Wasm2WasmOpt(MemoryUse): 487387136 bytes
```
We measure all metrics (compile-time, code size, memory use) separately
for dart2wasm and wasm-opt/binaryen. We also report total compilation
time as well as maximum memory usage across the tools.
Change-Id: I94c190475443b52d437a21ba85d5c5433f03dc50
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341486
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
The dart2wasm compiler treats wasm arrays of objects/ints/floats pretty
much the same, there's no reason to have complicated class hierarchy and
different kinds of wasm array classes.
Also: We rely on all operations on wasm arrays (and other built-in
types) to be handled on the call site. Wasm arrays are not dart objects,
don't support virtual dispatch. So we make operations operating on the
wasm types extensions.
This also makes now loads and stores into the wasm arrays simple `[]` and
`[]=` operations. We still have special extensions for reading/writing
to integer/double arrays that not only read/write but also
sign-extend/zero-extend and operate on Dart's `int` / `double`.
The compiler will allow `WasmArray<X>(length)` for types `X` that have
default-value in wasm arrays (nullable / integer / double types) and
have another `WasmArray<X>.filled(length, X)` for non-nullable reference
types.
Overall this reduces LOCs and simplifies things
Change-Id: I885bed3dfd1c602dc7b0747c69927d464376383d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340881
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Closes https://github.com/dart-lang/sdk/issues/54192
Callbacks were being casted to their static type before being
called. With generic callbacks, we do not know their exact type
at compile time, therefore cannot make that cast. Similarly, a
null check was being done if the static type of the parameter
was potentially non-nullable, whereas it should be done if it's
*not* potentially nullable.
Change-Id: I3d30e901f1ff2ae4c17887564f15368244baeb24
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340390
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Refactor `JSStringImpl` to use the js-string-builtins API[1].
When the module `WebAssembly.String` is not available we define a
"polyfill" with the previous imports, so this change is backwards
compatible.
Also updates some of the methods to use avoid multiple `this.length`
calls (which do an FFI call), and use unchecked getters when possible.
A new library `dart:_error_utils` is introduced for faster range and
index checks when the length (or max value) is known to be positive
(e.g. when it's the length of a string).
For now only `JSStringImpl` and `operator []` and `operator []=` of
`JSArrayImpl` are updated to use the new range and index checks. Rest of
the libraries will be updated separately.
[1]: https://github.com/WebAssembly/js-string-builtins
CoreLibraryReviewExempt: dart2wasm specific library change.
Change-Id: I9436def0cfe59c631f6f4e15ea06cc18a47a738e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335043
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@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>
In a forwarder for a method, check class IDs of all classes inheriting
the member and run the shape check once.
For example, in a this class hierarchy:
class A {
void printName() { print("A"); }
}
class B extends A {
void printName() { print("B"); }
}
class C extends A {}
When generating method forwarder for `printName`, we currently generate
a shape check for all classes.
This this CL we now generate two shape checks: one for A and C (which
share the same `printName`), one for B.
Secondly, when class IDs of a target contains a range of consecutive
class IDs, we now generate a range check, instead of a sequence of
checks for every class ID in the range.
Fixes#53880.
Change-Id: Ie7360075c7930262e9e18c7cd125b83fd32b4bfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339301
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This adds the `Native.addressOf` function, which takes a constant tear-
off of a method annotated with `@Native` as a parameter and returns a
pointer to the underlying C function.
The CFE will resolve these calls in two steps: First, the existing
transformer for `@Native` methods adds a pragma describing the fully-
resolved native annotation (with the asset id inferred from the library
if not given explicitly). Then, the FFI use sites transformer rewrites
calls to `Native.addressOf` by searching for this pragma on the passed
function and passing the `Native` constants to `Native._addressOf`. The
latter method is implemented in the VM, which can re-use existing parts
already used for `@Native` calls.
An alternative implementation strategy would have been to forward
`addressOf` calls to `Native.ffi_resolver_function` directly without
any special consideration in the VM. However, the chosen approach makes
it easier to support static linking in the future, as this requires
unresolved symbols in the generated assembly.
Closes https://github.com/dart-lang/sdk/issues/50552
TEST=pkg/vm/testcases/transformations/ffi/ffinative.dart
TEST=tests/ffi/native_assets/asset_*_test.dart
TEST=tests/ffi/vmspecific_static_checks_ffinative_test.dart
TEST=pkg/analyzer/test/src/diagnostics/ffi_native_test.dart
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64c-try,vm-aot-win-release-x64-try,vm-kernel-precomp-linux-release-x64-try
CoreLibraryReviewExempt: VM & dart2wasm only feature
Change-Id: Ic8e3a390146dffd44c95578f975a4472db79a0ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
- Move `TextDecoder` code to decode JS `Uint8Array`s as UTF-8 to its own
module `dart:_js_string_convert`.
- Use the module in default mode (non-JSCM) `dart:convert` when decoding
JS `Uint8Array`s.
Change-Id: I6921b2a99c37ec8920ab79482228ede777bf2b4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338520
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
`_Closure` is the implementation class for function objects. When used
as a type, it translated to the same Wasm type as the `Function` type,
but in the type system it missed the special property of `Function`
that it is a supertype of all functions. Instead, it was translated
into an interface type, leading to incorrect type check results.
Thus, we must always use the `Function` type when referring to any
function.
The problem was hidden by the type check specialization for simple
interface type checks and exposed by `--verify-type-checks`.
Change-Id: I384d35506c0c8cd932ba789e977f8257e684b8d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336423
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
This adds a `--verify-type-checks` option to dart2wasm to instrument
the code such that whenever we are able to generate specialized code
for a type check, we generate both the specialized code and also call
the general fallback path, then compare the results.
This can be used to expose bugs in the type check specializations, or
in the reference implementation, as it may be.
Change-Id: I081540a8eedc7d029b332919283810220b21b3ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336023
Reviewed-by: Ömer Ağacan <omersa@google.com>
stringref target won't be used any time soon (probably ever). To help
with build times and avoid keeping it updated remove it for now.
Change-Id: I0df33b7ab2e19bae5090e8ea32ea6a3dc3751652
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334881
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Users are allowed to have extension types on types that we allow
on external methods e.g. String. For most types, this doesn't make a
difference as we jsify for parameters and dartify and cast for return
types. The one place it does matter is when we check the static type
to do int conversions. Here, we should use the erased type instead.
Change-Id: Ibfcb0acc7f2c8a1ba3b52aa42000640982f11962
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335120
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a reland of commit b9b7de14e0
Previous version broke engine tests because of incorrect array impl
class (e.g. `JSUint16ArrayImpl`) to JS array externref conversion. Since
array implementation classes now store an `externref` to a `DataView`,
we can't use `toExternRef`, we need to use the new `toJSArrayExternRef`.
Original change's description:
> [dart2wasm] Use DataView in JS typed arrays
>
> Refcator JS typed array classes to store JS `DataView`s (instead of JS
> typed array with the matching type), and use V8's new optimized
> `DataView` imports.
>
> Brings JS typed array class performance from unusable to reasonable
> levels. In `SkeletalAnimation` benchmark:
>
> - Before: 1444 us.
> - After: 101 us.
>
> Future work:
>
> - Make immutable classes extend the mutable ones. This will allow `[]`
> calls to be always inlined in JSCM.
>
> - Move list mixin applications from the base class to implementation
> classes. This will allow members like `elementAt`, `forEach` etc. to
> have direct calls to other methods of the same class.
>
> - Try adding a `length` field to avoid JS calls in bounds checks.
>
> Change-Id: Ief6165fe9c4a825072077db820b105c4fca30dce
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/328920
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
> Commit-Queue: Ömer Ağacan <omersa@google.com>
Change-Id: If913aed837d09570b82b0f6dcb9553abb17fd708
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334468
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This reverts commit b9b7de14e0.
Reason for revert: Dart to Engine rolls are failing, please see
https://github.com/flutter/engine/runs/18494538711
Original change's description:
> [dart2wasm] Use DataView in JS typed arrays
>
> Refcator JS typed array classes to store JS `DataView`s (instead of JS
> typed array with the matching type), and use V8's new optimized
> `DataView` imports.
>
> Brings JS typed array class performance from unusable to reasonable
> levels. In `SkeletalAnimation` benchmark:
>
> - Before: 1444 us.
> - After: 101 us.
>
> Future work:
>
> - Make immutable classes extend the mutable ones. This will allow `[]`
> calls to be always inlined in JSCM.
>
> - Move list mixin applications from the base class to implementation
> classes. This will allow members like `elementAt`, `forEach` etc. to
> have direct calls to other methods of the same class.
>
> - Try adding a `length` field to avoid JS calls in bounds checks.
>
> Change-Id: Ief6165fe9c4a825072077db820b105c4fca30dce
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/328920
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
> Commit-Queue: Ömer Ağacan <omersa@google.com>
Change-Id: Iba46cfc409805bcd6f86bcc52a06ed8d54eea671
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335026
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Refcator JS typed array classes to store JS `DataView`s (instead of JS
typed array with the matching type), and use V8's new optimized
`DataView` imports.
Brings JS typed array class performance from unusable to reasonable
levels. In `SkeletalAnimation` benchmark:
- Before: 1444 us.
- After: 101 us.
Future work:
- Make immutable classes extend the mutable ones. This will allow `[]`
calls to be always inlined in JSCM.
- Move list mixin applications from the base class to implementation
classes. This will allow members like `elementAt`, `forEach` etc. to
have direct calls to other methods of the same class.
- Try adding a `length` field to avoid JS calls in bounds checks.
Change-Id: Ief6165fe9c4a825072077db820b105c4fca30dce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/328920
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Because of the special language rules (int +/-/* int = int),
static type for binary int operations can be more precise than
inferred result type (in case of dart2wasm, int binary operations
are declared as external methods returning num).
So, for dart2wasm it is useful to narrow result of a call by its
static type, if it is different from return type of the call target.
Also, this change fixes an incorrect static type which is
created during dart2wasm async* transformation.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/int_operations_dart2wasm.dart
Fixes https://github.com/dart-lang/sdk/issues/53921
Change-Id: Id6a5a2cffac47918c4e92f996267bf7fae713416
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333580
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
The implementation of `~/` is a bit more complicated than other
operators as it needs to handle some special cases, so we currently
don't generate inline code for it.
This causes generating indirect calls to `~/` in some cases even when
the static Dart type of the arguments are `int`s, see [1] for details.
Update the intrinsic matcher to specially handle this operator by
calling `_BoxedInt._truncDiv`, which is then inlined.
This leads to huge performance wins in [2] as typed data `length`
getters currently compiled to indirect calls to `~/`.
[1]: https://github.com/dart-lang/sdk/issues/53921
[2]: https://dart-review.googlesource.com/c/sdk/+/328920
Change-Id: I92d89db76af38b1f843e25a841074f00ff2ef30a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333381
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Refactor libraries so that JSCM will only use `JSStringImpl` class for
strings.
The goal is to disentangle the native string classes and `JSStringImpl`
and start testing `JSStringImpl` in isolation.
Changes:
- `dart:_string` is no longer available in JSCM.
- Make `int.toString` external to allow patching it differently in JSCM
and normal modes.
`toString` implementations are in `boxed_int_to_string.dart` patch
files.
- `int.parse` now uses JS `parseInt`. However `parseInt` is not
compatible with Dart's `int.parse` so this will cause some more test
failures in JSCM for now.
- Any dependencies to `dart:_string` from JSCM `dart:convert` are
removed. The library implementation now uses JS `TextDecoder` for
UTF-8 decoding.
Note: `TextDecoder` is not available on d8, so text decoding tests
will fail on d8.
JSON encoding and decoding in `dart:convert` will be updated in a
follow-up CL.
- Compiler (translator, constant generator, code generator etc.) is
updated to allocate the `JSStringImpl`s in JSCM.
Initially this will make some JSCM test fail as `int` parsing is not
quite right, those will be fixed in follow-up CLs.
Co-authored-by: Joshua Litt <joshualitt@google.com>
Change-Id: I366e06f44cdc369d28fe47b24015234260304399
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332680
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This adds the representation field of an extension type declaration
as an abstract getter in the ExtensionTypeDeclaraiton marking it as
a ProcedureStubKind.RepresentationField
These are never used as interface targets and are therefore skipped
in the type flow analysis.
TEST=existing
Change-Id: Ie645e63e0995a31895e985a2025dccb1476d16bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330782
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This is a reland of commit 2cbb5eabca
This removes the optimization that would reuse the Wasm struct of the
superclass if no new fields were added in a class. Such reuse
interferes with debugging.
Binaryen performs a similar optimization in its TypeMerging pass. It
seems to be doing a better job with the more precise type information
provided after this change. Benchmarks show a positive trend.
The change uncovered a number of latent bugs in the compiler, which
are also fixed in this CL:
- References to `StackTrace` objects must be typed with the
representation type of `StackTrace`, rather than its struct type.
- The dynamic call vtable entry and dynamic invocation forwarder
functions must use `_ListBase` rather than `_List` for their
parameters, since we sometimes pass growable lists to these
functions.
- Most covariant parameters must use the top type, since any object
can be passed into such parameters via class type parameter
covariance or tear-offs.
The change makes us fail a number of tests with very deep class
hierarchies due to the Wasm subtyping depth limit of 63. The
optimization did not absolve us from this limitation. It just made us
only count classes with newly added fields.
The limitation is not expected to cause any problems for real code.
The maximum subclassing depth that occurs in the Flute benchmark is
11. FWIW, Java has a limit of 60.
The limitation is mentioned along with other limitations in
https://github.com/dart-lang/sdk/issues/53703
Change-Id: I9f541049d2020934e98b2042a7d9852305f17ec1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330341
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Now that we have our own `dart:convert` implementations in dart2wasm
targets (1) and the internal types are now internally public (2), this
simplifies some of the string implementation code by using the
implementation classes directly.
Note: stringref patch can be ignored, it's currently unused and I'm only
updating it to make it compile. It will be rewritten based on
`JSStringImpl` in [3].
To keep the CLs as small as possible, this CL does not do any of the
optimizations we can do now, such as optimizing
`OneByteString._setRange` to Wasm `array.copy` instructions. These will
be done in follow-up CLs.
[1]: https://dart-review.googlesource.com/c/sdk/+/330781
[2]: https://dart-review.googlesource.com/c/sdk/+/330783
[3]: https://dart-review.googlesource.com/c/sdk/+/316628
Change-Id: I92918d58a565ad32f5a221430e02d81562f03b00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331040
Reviewed-by: Jackson Gardner <jacksongardner@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This is a part of [1] and a continuation of [2].
- Make typed data implementation file a library, to allow importing it
in `dart:convert` patch.
- Make SIMD implementation file a library, to allow importing it from
the typed data library.
- Make typed data implementation classes internally public (available in
other `dart:...` libraries).
- Relax `mayDefineRestrictedType` to allow implementing restricted types
anywhere in the standard library implementation.
[1]: https://dart-review.googlesource.com/c/sdk/+/330121
[2]: https://dart-review.googlesource.com/c/sdk/+/330781
Change-Id: I70bc6869a20fd2479bee081cfceef27d6de19974
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330783
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Jackson Gardner <jacksongardner@google.com>
This change adds propagation of closure values to TFA.
For now, inferred closure values are used only when they are
constant (tear-off of a static method or a constructor).
Arbitrary closures can now be referenced from unrelated
members via closure-id metadata.
In addition, this change fixes an incorrect stack trace when
an implicit closure (tear-off) was propagated and its call was
inlined. Inlining interval was not recorded because of the missing
source position of a call to a target method within implicit closure.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/closures.dart
Issue: https://github.com/dart-lang/sdk/issues/39692
Change-Id: I3590da91b6057e0b55a8614382dba1bbcc267b39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325447
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The type normalization rules specify that `FutureOr<T>?` is normalized
to `FutureOr<T>` when `T` is nullable. However, it's more practical
for subtype testing if the declared nullability on the runtime
representation of the `FutureOr` type reflects the true nullability
(nullable if the `FutureOr` is declared nullable or its type argument
is nullable), rather than being normalized as per the spec.
This changes the static and dynamic normalization rules in dart2wasm
thus and compensates by computing the proper spec normalization when
the type is converted to a string.
The added test exposed a number of bugs in DDC and the VM:
https://github.com/dart-lang/sdk/issues/53175https://github.com/dart-lang/sdk/issues/53737https://github.com/dart-lang/sdk/issues/53738
Change-Id: I0ad0a09fe935ccbd3eb65e6958c958d29e0bb088
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320821
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
This reverts commit 2cbb5eabca.
Reason for revert: https://github.com/flutter/flutter/issues/136363
Original change's description:
> [dart2wasm] Use a separate Wasm struct for every Dart class
>
> This removes the optimization that would reuse the Wasm struct of the
> superclass if no new fields were added in a class. Such reuse
> interferes with debugging.
>
> Binaryen performs a similar optimization in its TypeMerging pass. It
> seems to be doing a better job with the more precise type information
> provided after this change. Benchmarks show a positive trend.
>
> The change uncovered a number of latent bugs in the compiler, which
> are also fixed in this CL:
> - References to `StackTrace` objects must be typed with the
> representation type of `StackTrace`, rather than its struct type.
> - The dynamic call vtable entry and dynamic invocation forwarder
> functions must use `_ListBase` rather than `_List` for their
> parameters, since we sometimes pass growable lists to these
> functions.
> - Most covariant parameters must use the top type, since any object
> can be passed into such parameters via class type parameter
> covariance or tear-offs.
>
> The change makes us fail a number of tests with very deep class
> hierarchies due to the Wasm subtyping depth limit of 63. The
> optimization did not absolve us from this limitation. It just made us
> only count classes with newly added fields.
>
> The limitation is not expected to cause any problems for real code.
> The maximum subclassing depth that occurs in the Flute benchmark is
> 11. FWIW, Java has a limit of 60.
>
> The limitation is mentioned along with other limitations in
> https://github.com/dart-lang/sdk/issues/53703
>
> Change-Id: Ifaa23d8278989e2549c41696d8913e55ed1e80aa
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324460
> Commit-Queue: Aske Simon Christensen <askesc@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
Change-Id: I1b16936a045f6297f340b5d72344f702446bf955
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330044
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Auto-Submit: Jackson Gardner <jacksongardner@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This renames ExtensionType.typeErasure and adds it to DartType. This also fixes the extension type erasure for when extension types are used in the arguments of an extension type.
DartType.extensionTypeErasure can be used by backends to easily
access the type without extension types for any type.
TEST=pkg/kernel/test/extension_type_erasure_test.dart
Change-Id: Ia49d273ed85111e3ae822720860a3e0be5ea0252
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329960
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This removes the optimization that would reuse the Wasm struct of the
superclass if no new fields were added in a class. Such reuse
interferes with debugging.
Binaryen performs a similar optimization in its TypeMerging pass. It
seems to be doing a better job with the more precise type information
provided after this change. Benchmarks show a positive trend.
The change uncovered a number of latent bugs in the compiler, which
are also fixed in this CL:
- References to `StackTrace` objects must be typed with the
representation type of `StackTrace`, rather than its struct type.
- The dynamic call vtable entry and dynamic invocation forwarder
functions must use `_ListBase` rather than `_List` for their
parameters, since we sometimes pass growable lists to these
functions.
- Most covariant parameters must use the top type, since any object
can be passed into such parameters via class type parameter
covariance or tear-offs.
The change makes us fail a number of tests with very deep class
hierarchies due to the Wasm subtyping depth limit of 63. The
optimization did not absolve us from this limitation. It just made us
only count classes with newly added fields.
The limitation is not expected to cause any problems for real code.
The maximum subclassing depth that occurs in the Flute benchmark is
11. FWIW, Java has a limit of 60.
The limitation is mentioned along with other limitations in
https://github.com/dart-lang/sdk/issues/53703
Change-Id: Ifaa23d8278989e2549c41696d8913e55ed1e80aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324460
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Martin Kustermann