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>
- Break false dependency of non-VM platforms on VM platform
- Break false dependency of bootstrap gen_kernel on VM platform
- Extend precompile_tools to gen_kernel steps
- Rename intermediate kernel files so JIT versus AOT is visible in ninjatracing
TEST=ci
Change-Id: I07011abe8303597af61d2b8c73e788b661482cc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510060
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
The front-end, dart2js, dart2wasm, ddc and analyzer bots do not need the cross-compilation or sanitizer tools, nor the VM test binaries.
Change-Id: I2f5a1041b1b29c562bace7210830e9904a31c397
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510040
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Measured on size of e main module (baseline is we don't embed
it in application code):
* embedding before: +16.5% uncompressed / +9.1% compressed
* embedding with this CL: +4% uncompressed / +4.3% compressed
When embeddeding deferred load list information into the app
(as opposed to a separate json file) we now use a more compact
encoding.
Specifically: Instead of encoding it as an array of an array of
strings (which are module names), we encode it as an array of an
array of module ids and construct the module name from the id.
To make the array of module ids more compact we utilize the fact
that we can sort them and encode in delta encoding (i.e. instead
of absolute module ids, encode the diff between previous module
id in the list).
We put the encoded module id lists in a data section and create
`WasmArray<WasmI8>`s from them at startup. When we trigger a load
we then decode them into the list of module names.
There's more opportunity to optimize it, but it's good to do
this as a first step.
Change-Id: I293fb8879d992fc370786f6c9b258ccd27e1559b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508980
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
In a valgrind "profile" of a run of an aot-compiled version of
`pkg/analyzer/tool/stable_analysis.dart` I noticed that
`_OperatorEqualsAndHashCode._hashCode` was called 40,288,281 times,
costing - by itself, i.e. without the actual cost of getting the
underlying hashCode - 723,483,274 instructions - about 1.79% of the
total cost.
Interestingly `_OperatorEqualsAndHashCode._equals` wasn't there, so that
one must be inlined (whereas the `_hashCode` isn't). Stepping via GDB
confirms both things.
Via the inlining tracing in the vm via
```
out/ReleaseX64/dart-sdk/bin/dart \
compile aot-snapshot --verbose \
--extra-gen-snapshot-options="--print_inlining_tree" \
pkg/analyzer/tool/stable_analysis.dart
```
I found
```
Inlining into: 'dart:_compact_hash___Map&_LinkedHashBase&MapMixin&_HashBase&_OperatorEqualsAndHashCode&_LinkedHashMapMixin@3099033_[]='
growth: 0.000000 (9 -> 0)
NO 14 __Map&_LinkedHashBase&MapMixin&_HashBase&_OperatorEqualsAndHashCode@3099033._hashCode@3099033 - Heuristic fail (no small leaf)
NO 16 __Map&_LinkedHashBase&MapMixin&_HashBase&_OperatorEqualsAndHashCode&_LinkedHashMapMixin@3099033._set@3099033 - Not inlinable
```
In `runtime/vm/compiler/backend/inliner.cc` I saw that I could avoid
this "no small leaf" thing by marking it for inlining.
Running stable_analysis through `perf stat` without and with this CL I
get:
```
Without CL:
39,552,232,456 instructions:u
39,552,392,619 instructions:u
39,554,905,123 instructions:u
```
```
With this CL:
39,024,836,004 instructions:u
39,022,158,372 instructions:u
39,022,782,198 instructions:u
```
So this "only" saves something like 527 million instructions (~1.3%),
i.e. less than the ~723 million instructions hoped for, but I'll take
it.
Change-Id: I07a8fb097e46ab48c26bcf7896b12c7312ededc3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509000
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Given that the standalone target for dart2wasm is feature-complete now,
it makes sense to include it in released SDKs.
This adds the platform and outline files to built SDKs and exposes the
`--standalone` flag in `dart compile wasm`.
It also documents the standalone target in `pkg/dart2wasm/doc`, which
should be helpful as a starting point to use these compiled modules.
Change-Id: I5bd86e9670f03f2955e31789095dd5c462bf149e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506920
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This will make GN notice conflicting copy_tree destinations.
It may also fix a race when two copy_tree's with a common parent directory create that parent directory.
Change-Id: I1783ea170f0390d4026123ed43c00cd15eb0b1c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508241
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
The previous attempt was reverted because it broke unoptimized JIT
on ARM 32. This reland force-optimizes the two getters.
Stacks on top of the int.{trailingZeroBitCount,oneBitCount} API CL
(commit 754239b077). Both getters route through OTHER_RECOGNIZED_LIST
when a hardware fast path is available; otherwise the newly added
Dart bodies inline at call sites via vm:prefer-inline. The C++
natives are removed.
Backend codegen
---------------
ARM64: NEON CNT + UADDLV (popcount); RBIT + CLZ (ctz).
ARM: NEON CNT + VPADDL chain (popcount); RBIT + CLZ on the
register pair (ctz).
x64: popcntq when TargetCPUFeatures::popcnt_supported();
LoadImmediate(64) + rep_bsfq for ctz (decodes as tzcnt
on BMI1+, preserves dest on zero otherwise).
RISC-V 64: cpop / ctz when RV_baseline includes Zbb.
Per-arch availability is encapsulated in
UnaryInt64OpInstr::IsSupported(Token::Kind).
Apple M-series ARM64, AOT (us/iter, lower is better):
cardinality.swar 371
cardinality.accelerated 154 (2.4x)
forEachSetBit.swar 19031
forEachSetBit.accelerated 4988 (3.8x)
select.swar 199
select.accelerated 77 (2.6x)
complementCardinality.swar 399
complementCardinality.accel 152 (2.6x)
Work towards https://github.com/dart-lang/sdk/issues/6486 (popcount
and ctz intrinsification).
Work towards https://github.com/dart-lang/sdk/issues/1053 (efficient
BitSet implementation).
Fixes https://github.com/dart-lang/sdk/issues/52673
Fixes https://github.com/dart-lang/sdk/issues/38346
Fixes https://github.com/dart-lang/sdk/issues/63436
Issue https://github.com/dart-lang/sdk/issues/10212
Issue https://github.com/dart-lang/sdk/issues/5798
TEST=tests/corelib/int_bit_count_test
Cq-Include-Trybots: luci.dart.try:vm-linux-release-simarm-try,vm-ffi-qemu-linux-release-arm-try,vm-aot-linux-release-simarm_x64-try,vm-aot-linux-debug-simarm_x64-try,dart-sdk-linux-riscv64-try
Change-Id: Ib812cbaec6e371b9720df7a543411f78e524cac1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506060
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Issue #55173.
Exposes signed min/max on WasmI64 and f64.min/f64.max on WasmF64 in
dart:_wasm, mirroring how WasmF64.sqrt is exposed today. The dart:math
min/max patches in math_patch.dart dispatch to them via runtime
`is`-checks, with @pragma('wasm:prefer-inline') so the inliner folds
the chain to the bare instruction sequence at each call site:
T min<T extends num>(T a, T b) {
if (a is int && b is int) return unsafeCast<T>((a as int).minS(b));
if (a is double && b is double) return unsafeCast<T>((a as double).min(b));
return _minSlow<T>(a, b);
}
Wasm has no native i64 min_s/max_s, so WasmI64.minS/maxS emit the
same local.tee + i64.le_s/ge_s + select sequence. WasmF64.min/max emit
f64.min/f64.max directly.
The NaN- and signed-zero-aware fallback ladder is preserved in
`_minSlow` / `_maxSlow` (out-of-line, no pragma) and called for the
mixed and num cases. tests/lib/math/min_max_test.dart requires type
preservation between equal int and double arguments (e.g.
min(-499, -499.0) is int at line 113; max(499, 499.0) is int at
line 382), which a toDouble().max(toDouble()) fallback would not
satisfy.
Adds pkg/dart2wasm/test/ir_tests/math_min_max.dart covering min/max
for static int/int, double/double, mixed int/double, and num/num.
The .wat locks in f64.min/f64.max for the f64 paths, i64.le_s/i64.ge_s
+ select for the i64 paths, and `call $_minSlow` / `call $_maxSlow`
for mixed and num/num.
Measurements on a probe with four typed call sites (one each for
min<double>, max<double>, min<int>, max<int>, all marked
@pragma('wasm:never-inline')):
* .wasm size: 27,112 → 25,848 bytes (-4.66%). Generic $min and $max
are eliminated by DCE.
* Runtime, 100M iterations per operation on d8, median of 10 runs:
min<double> 543 → 213 ms (2.55x), max<double> 550 → 213 ms (2.58x),
min<int> 552 → 65 ms (8.49x), max<int> 555 → 73 ms (7.61x).
Checksums match between baseline and patched.
tests/lib/math/min_max_test.dart passes.
R=mkustermann@google.com, osa1@google.com
Change-Id: If8cf0a4df976f2d7f2230308905ff68491311c97
Bug: https://github.com/dart-lang/sdk/issues/55173
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503740
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Implement api methods to create and shutdown isolates from IsolateGroup-bound callbacks (normally invoked from native code), run dart code on such isolates.
The rest of the api is not implemented yet.
TEST=tests/ffi/threading_test.dart
BUG=https://github.com/dart-lang/sdk/issues/62407
CoreLibraryReviewExempt: vm-only change to isolate library
Change-Id: I0271ead8ba011dfe9d7953769415d6a88a962854
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486522
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The dart2wasm compiler can use three different SDK platforms depending
on compiler options: The default one, a JS compatibility target and a
standalone target.
Code for these platforms used to be in `_internal/` subdirectories, but
parts of `_internal/wasm/lib` were also used by the other targets.
To make it clearer which patches/internal libraries belong to which
target, this restructures `_internal/wasm` as follows: Files only
relevant for one target are in `js`, `js_compatibility` and
`standalone`. Files used by all targets are in `common`, files used in
the default and the JS compatibility target are in `js_common`.
TEST=Refactor, covered by existing tests
Change-Id: I2c63c04a5fd5ca88cd640889aa295bd1fb8cfc95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505441
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Fixes#63418
When IOOverrides are active, `fseGetType` and `fseGetTypeSync` used
`utf8.encode(path)` which does not null-terminate the path. Native
APIs require null-terminated paths. Through luck the sync path worked
but the async path failed with `notFound`.
Update them to use `FileSystemEntity._toUtf8Array(path)` which correctly
null-terminates the path.
Tested: added a regression test to tests/standalone/io/io_override_test.dart
TAG=agy
CONV=ab6af504-d536-4a8d-88be-bc487b60e24d
R=bkonyi@google.com
CoreLibraryReviewExempt: No API changes.
Change-Id: I24e31efdcbecc703800b96a144e41a095a445cff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505201
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Stacks on top of the int.{trailingZeroBitCount,oneBitCount} API CL
(commit 754239b077). Both getters route through OTHER_RECOGNIZED_LIST
when a hardware fast path is available; otherwise the newly added
Dart bodies inline at call sites via vm:prefer-inline. The C++
natives are removed.
Backend codegen
---------------
ARM64: NEON CNT + UADDLV (popcount); RBIT + CLZ (ctz).
ARM: NEON CNT + VPADDL chain (popcount); RBIT + CLZ on the
register pair (ctz).
x64: popcntq when TargetCPUFeatures::popcnt_supported();
LoadImmediate(64) + rep_bsfq for ctz (decodes as tzcnt
on BMI1+, preserves dest on zero otherwise).
RISC-V 64: cpop / ctz when RV_baseline includes Zbb.
Per-arch availability is encapsulated in
UnaryInt64OpInstr::IsSupported(Token::Kind).
Apple M-series ARM64, AOT (us/iter, lower is better):
cardinality.swar 371
cardinality.accelerated 154 (2.4x)
forEachSetBit.swar 19031
forEachSetBit.accelerated 4988 (3.8x)
select.swar 199
select.accelerated 77 (2.6x)
complementCardinality.swar 399
complementCardinality.accel 152 (2.6x)
Work towards https://github.com/dart-lang/sdk/issues/6486 (popcount
and ctz intrinsification).
Work towards https://github.com/dart-lang/sdk/issues/1053 (efficient
BitSet implementation).
Fixes https://github.com/dart-lang/sdk/issues/52673
Fixes https://github.com/dart-lang/sdk/issues/38346
Issue https://github.com/dart-lang/sdk/issues/10212
Issue https://github.com/dart-lang/sdk/issues/5798
TEST=tests/corelib/int_bit_count_test
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-simarm_x64-try,vm-aot-linux-debug-simarm_x64-try,dart-sdk-linux-riscv64-try
Change-Id: I9c2c4225fd63d54e190398a0fb6649366317dd17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504221
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Some features in `dart:_wasm` are relevant for all WebAssembly targets
(like interop types or memory intrinsics). Others, in particular the
helper methods to convert between `WasmExternRef` and `JSAny`, don't
make sense for the standalone target.
To be able to remove the `js_interop` library from the standalone
target, we need to stop importing it from `dart:_wasm`. To prepare that
step, this moves the helpers to a new library (`dart:_js_interop_wasm`)
and re-exports them from `dart:_wasm`.
Once Flutter has migrated to the new import, the export can be removed.
Bug: https://github.com/dart-lang/sdk/issues/63166
Change-Id: I13fe875e509a13d16c48d420a5927d3130b90736
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505080
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Simon Binder <oss@simonbinder.eu>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The standalone target used `JSStringImpl` as the name for its string
implementation even though JavaScript isn't involved in that at all.
This was to simplify parts of the compiler which can then refer to both
classes with the same name.
Changing this in the compiler is not that complicated however, so it
makes sense to align the string implementation name with the embedder
terminology we also use for other host imports.
TEST=pkg/dart2wasm/test/ir_tests/standalone.{dart,wat}
Change-Id: I1e112c8a72bb43a7edfa73ff7205d353edc7403a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504581
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This migrates the `String` implementation from using JS interop to
explicit host imports for the standalone target.
This moves a few helper methods shared between the JS and standalone
targets to `dart:_string_helper`. This also moves the embedder regexp
implementation to `dart:_string` to be able to access internals in some
string methods (similar to how the JS implementation special-cases
`JSSyntaxRegExp`).
This removes the final real use of JS-interop in the standalone target.
So, we can:
- Remove internal JS helper libraries from the target.
- Skip JS-interop transformations in the compiler.
- Stop emitting a helper module and support script.
Because `js_interop` is imported in `dart:_wasm`, we can't remove the
library entirely. This replaces it with a stub to avoid compilation
errors, a proper removal is tracked in dartbug.com/63166.
Change-Id: Ide495c210c3a272438deebf8fe4f3f44ba314ffa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501960
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit 2a93a26d91, which a change to use `defined` so that the GN script does not crash in
Flutter.
Fixesflutter/devtools#9786
See go/moving-devtools-to-dart-sdk-2025.
In this change, we make the source of devtools be configurable, in
actions like build_sdk.
If `build_devtools_from_sources` is true, we build local devtools,
and if false, we continue to use the prebuilt sources.
This may be an intermediate step, while we test out building devtools
from source. Or it may be permanently be a choice, if we keep building
with CIPD.
Change-Id: I9d509b07971942f2c4884224a6efda9001522bd4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502120
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Adds isSystemIsolate in the isolate startup message sent to the
VM service, allowing for the service to identify the first non-system
isolate as the root isolate.
TEST=Existing tests
CoreLibraryReviewExempt: dart:vmservice is internal.
Change-Id: I0a982a1fc06bd0be0426ad9d1401e89375cbed40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500000
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Jessy Yameogo <yjessy@google.com>
When there's no expression on the stack but we expect something on the
stack, then the code should be unreachable.
Though the current code would just synthesize a value that matches
the expected type (`convertType(voidMarker, <some type>)`). This
is problematic: If we ever used that synthesized value we may
have incorrect program behavior.
Now there were some valid uses where we synthesize values
* A function that has `void` return type but no explicit return
=> Here we should synthesize `null`
* Synthesize `null` in cases where we know it's not going to be used
=> e.g. for CFE desugaring of `a[i] = b` is roughly
`let tmp = b in (let ignored = a.[]=(tmp) in b)`
where we synthesize `null` as `a.[]=(tmp)` result,
`ignored` isn't used.
* ...
With this CL we no longer allow synthesizing a value of a type
out of thin air, instead all the places where this occurs have
to do that explicitly.
There's some impurities around how setters and index setters
are handled today (and even after this CL). Those impurities
start all the way at CFE, which treats setters and index
setters very differently. See the CFE issue [0].
For those we have two choices:
* special case all call sites that require synthesizing
null values
* special case all call sites that require dropping an
auto synthesized null value
This CL now marks instance setter/index-setter methods as
requiring auto-synthesizeing null values on usage sites and
make code that doesn't need them explicitly drop them.
Somewhat related to this change is how we deal with `void`
on the Dart <-> Wasm Import / Wasm Export boundary: When we
call an imported wasm function that has `void` as return
type (meaning no return values) we have to synthesize a `null`
(as the caller may "use"/"observe" the `void`).
=> We now are more strict and instead use `WasmVoid` as type
instead of allowing `void` as type on the import/export
functions.
[0] https://github.com/dart-lang/sdk/issues/63360
Change-Id: Ie30df3bd68553724437607bab3163c98f5467efe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501061
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This test verifies how deoptIds and environments are set
when inlining force-optimized functions.
The problem is that it looks at the chain of inlined calls:
foo() {
call1 -> Pointer.fromAddress
}
Pointer.fromAddress() {
call2 -> _fromAddress
}
// force-optimized
_fromAddress() { ... }
During inlining of force-optimized callee, its instructions
should receive deoptId/env from inlined call site.
In this case, the call site is 'call2'.
However, the test has been matching deoptId/env with 'call1'.
It was a mere coincidence that deoptIds of call1 and call2
were the same. Any attempt to make a change which would
affect deoptIds within Pointer.fromAddress breaks this test.
In order to fix this, a simpler setup is now used:
foo() {
call1 -> newHash()
}
// force-optimized
newHash() { ... }
Also, the check for deoptId of outermost environment is dropped as
in this case there are no multiple environments.
In addition, also remove the duplicate pragma from _fromAddress.
TEST=vm/cc/Inliner_InlineForceOptimized
Change-Id: I1f592a74dfb8b7c2f67f3b0a51e7f7b74bf358eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502801
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Adds two new getters to int for bit-counting: trailingZeroBitCount
(ctz) and oneBitCount (popcount). On native platforms they operate
on the full 64-bit two's-complement representation; on the web they
operate on the least-significant 32 bits.
Implementations:
- VM: unified C++ natives Integer_trailingZeroBitCount /
Integer_oneBitCount on _IntegerImplementation, using
Utils::CountTrailingZeros64 and Utils::CountOneBits64. The receiver
may be _Smi or _Mint at runtime.
- dart2js / DDC: clz32-based ctz and a SWAR popcount.
- dart2wasm: inlined i64.ctz and i64.popcnt intrinsics.
leadingZeroBitCount (clz) is intentionally excluded from this CL: its
result depends on the platform integer width (e.g. 1.leadingZeroBitCount
is 31 on web, 63 on native), and the same value can be derived from
the existing bitLength getter when needed.
Asm intrinsification on native architectures is intentionally left for
a separate follow-up CL.
Work towards https://github.com/dart-lang/sdk/issues/6486 (this CL
covers popcount and ctz from the bit-twiddling list; clz, rotate,
reverse, and others remain).
Work towards https://github.com/dart-lang/sdk/issues/1053 (efficient
BitSet implementation).
Bug: https://github.com/dart-lang/sdk/issues/52673
Bug: https://github.com/dart-lang/sdk/issues/38346
TEST=tests/corelib/int_bit_count_test
Change-Id: I8a5cdb5c91360478f47bbd6b9c84ca1c477aa8c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498041
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Add a check both in the native implementation and on the Dart side (to
avoid throwing uncatchable ApiError).
Simplify native implementation: Dart_ListGetAsBytes has fast path for
byte sized typed data lists, so there is no reason to inline the
same fast path into the caller.
Reported by Kyounghwan Kim (@drg2533)
TEST=runtime/tests/vm/dart/regress_b508627933_test.dart
Bug: b/508627933
Change-Id: I14c0f5270f143ed2386200241b13313f6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500461
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
`List.unmodifiable` and `Map.unmodifiable` is as badly typed
as `List.from` and `Map.from`, but does not have a better-typed
`.of` constructor. This adds such, to give a migration target
when deprecating the badly typed constructors.
The `Future.delayed` with no second argument is also unsafely
typed, it fails if the type argument is not nullable.
The `Future.pause` creates `Future<void>` instead.
CoreLibraryReviewExempt: No new or platform specific behavior.
Change-Id: Iba101b3dc62f412003abd501fa042aca0ce63116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499280
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
This replaces js-interop and `JS(...)` usages in patches for
`dart:core` in the dart2wasm standalone target with explicit host
imports.
This still uses JS strings as a string implementation, so js-interop
from `dart:core` hasn't been removed completely. Migrating strings will
require additional changes - mainly to `dart:js_interop` itself, which
we want to remove from the standalone target anyway. So, I believe it
makes sense to migrate strings last.
In most cases, these imports match the manual JavaScript we've used
before. `StringBuffer`s are an exception here, the default platform
implements them via string concatenation but some embedders might
benefit from explicit string buffers.
TEST=tests/corelib/**
Change-Id: I1ea18ac30bac24b30e528b2c28d925fda886c988
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491480
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This reduces e main module by around -0.3%.
We make the inliner have more precision when estimating the
callee size, especially around constructors but also other
cases.
We are also less generous with budget for iterators, modulo list
iterators which we want to be always inlined.
We also print the inlining decisions in `--print-wasm`
In deferred loading scenario this now inlines constructor bodies
more often than before as the size estimate is better. That in
return avoids us e.g. exporting empty constructor body functions
in the main module to be imported by other modules.
CoreLibraryReviewExempt: Backend-specific function changes.
Change-Id: I320db6f976a5d8c036b40908a5f72e7019d420ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498562
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Martin Kustermann