E.g.
```
final bool foo = (1+1==2) ? true : false;
if (foo) {
if (foo) {
print("always true");
}
if (!foo) {
print("always false");
}
}
```
Inside the first if we know `foo` to be true, so there's no reason to do
more if's on it.
Change-Id: I87d0827c47ce0e7277d951c0ec28f19dff09767a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338780
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@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>
This adds a list of `Procedure`s to `ExtensionTypeDeclaration`. This is
meant to model representation fields and combined member signatures
computed from inherited non-extension type members.
These are not meant to be handled by the backends. The combined
member signature can be the interface target of an `InstanceInvocation`
expression but will always have a `.memberSignatureOrigin` value from
one of the original class members.
TEST=existing
Change-Id: I87768ed75a3c7126b0a30f8ccf06e46678c56db6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330301
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL introduces StructuralParameter and StructuralParameterType
classes. They are intended to replace TypeParameter and
TypeParameterType respectively where those were used as type
parameters defined by FunctionTypes. Previously, type parameters of
FunctionTypes were represented by TypeParameter objects with the
‘parent’ field set to null. By introducing StructuralParameter and
StructuralParameterType this CL unambiguously separates the two
notions of type parameters.
TEST=existing
Change-Id: Ida3feb7ad96a7b2acef55840eacba9e36bf2a3e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312264
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This splits visitors for (Tree)Visitor(1) into pure interfaces, mixins,
and a base class with the base implementation. This is a step towards
avoid having an accidental default implementation where a static error
would have been preferable.
This extract a ConstantReferenceVisitor(1) and its corresponding
DefaultMixin from the Visitor(1) interface.
TEST=existing
Change-Id: Ibc55bed9cff76581deaade91a10600c17fafc6dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325704
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This updates the generator of experimental flags to only refer to one
location for the current default language version.
Semantically the change does nothing, but it could make CLs that bump a
version smaller and easier to revert/patch.
Change-Id: I1c18c8e8105dfb33a302949ad2cfa159dae2addf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325660
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This renames InlineClass to ExtensionTypeDeclaration, and InlineType
to ExtensionType. Members of extension type declarations are called
extension type members instead of extension type declaration members
for "brevity".
TEST=existing
Change-Id: I91ed62533ddd345644492f04dc3310d007460288
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This removes ExtensionType, ExtensionTypeShowHideClause and
CallSiteAccessKind from package:kernel which where only used by the now
removed 'extension-types' experiment.
A follow-up CL will rename InlineClass/InlineType to
ExtensionTypeDeclaration/ExtensionType to match the names of the
Extension Type feature currently being implemented.
TEST=existing
Change-Id: I58d2e8b0a92ac61329ee161cc6884a2c0e6f87ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316420
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The purpose of the wasm_js_compatibility target is to facilitate experiments with a JS compatibility mode for Dart2Wasm. Initially, we're just going to focus on typed data, but this will give us a place to experiment with moving List and String to JS as well.
In addition, someday down the road we hope to experiment with two additional compatibility changes:
1) Exclusively using double for all Dart numbers
2) Allowing undefined to flow as null.
The two major benefits of this approach are:
1) Much faster JS interop
2) To make it easier to bring up Dart2JS applications on Dart2Wasm
The only downside will be access overhead on the Wasm side, but the JS builtins proposal could potentially bring us close to parity with Wasm builtins someday.
Tested: Wasm specific trivial refactor.
Change-Id: I2c09426b6999507c1de6e584e9bc7072a088bda9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313240
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Right now `utf8.encode()` has a static return type of `List<int>`
due to extending `Encoding` (which extends `Codec<String, List<int>>`).
We cannot easily change `Encoding` to extend `Codec<String, Uint8List>`
because that would also change `utf8.decode()` to require `Uint8List`
which would be a breaking change.
So instead we override `utf8.encode()` to have more precise return type.
Some parts of our SDK are run using the checked-in SDK, so it cannot
rely on the changed return type yet (until checked-in SDK is rolled).
So we use `const Utf8Encoder().convert()` as a temporary change, as
that already has `Uint8List` return type.
Issue https://github.com/dart-lang/sdk/issues/52801
TEST=ci
CoreLibraryReviewExempt: More precise return type for existing API
Change-Id: I2861d1f0eb3d292d8e3ec8437c0d441a2d2bd193
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254903
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
This adds basic infrastructure for a stringref implementation in
dart2wasm:
- A `--[no-]stringref` option to the compiler
- An option in the `WasmTarget`, controlling the name of the target
- Separate sets of patch files for the two targets
- Separate platform dill files for the two targets
For now, the patch file contents are the same, and the compiler flag
is not used by the backend (only by the `dart2wasm` script to select
the appropriate platform dill file). Both of these will change as the
implementation progresses.
Tested: ci + manual check that the option selects the correct dill
Change-Id: I2c9bb95ba06fd3de3f7007703ef545e3f0c728ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310621
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Tool that runs two or more aot-snapshots in the same way through perf
stat, then performing statistics on the result.
This generally runs
```
perf stat -B taskset -c 7 out/ReleaseX64/dart-sdk/bin/dartaotruntime \
--deterministic <snapshot> <arguments>
```
a number of times, doing statistics on the data from `perf stat`.
Note that this makes it only run on 1 core as that seems a little more
stable, though it's normally not necessary. The `--deterministic` is
necessary though.
Change-Id: I4846972598eb4d019a44e7bbd2314f0b6d2aaa47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303340
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change:
* Fixes now-wrong asserts from when the origin of this was written
years ago (the new async reality also allowed for simplification
of the replacement code).
* Allows `*` as a wild-card name when processing candidates,
so for instance `flow_analysis.dart|*` would mean everything in
the file `flow_analysis.dart`.
* Allows taking the candidates via the command line without going
through a file, so instead of having a file with
`flow_analysis.dart|*` and passing that file with
`--candidates=file` one say "--candidates-raw=flow_analysis.dart|*"
- one can also give more either by giving it several times or by
comma-separating it.
* Adds two new instrumentations: `--single-timer` and `--timer`
where the first gives a single time for how long all instrumented
stuff was on the stack, and the second one gives a timer for each
instrumented procedure/constructor where it is on the stack.
One can for instance now instrument like this:
```
out/ReleaseX64/dart --enable-asserts pkg/front_end/tool/flame/instrumenter.dart -Diterations=10 pkg/front_end/tool/_fasta/compile.dart --single-timer "--candidates-raw=flow_analysis.dart|*"
```
or
```
out/ReleaseX64/dart --enable-asserts pkg/front_end/tool/flame/instrumenter.dart -Diterations=10 pkg/front_end/tool/_fasta/compile.dart --timer "--candidates-raw=flow_analysis.dart|*"
```
And it can be run via
```
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill pkg/front_end/tool/_fasta/compile.dart
```
And produce something like this (note that these examples are with -Diterations=10 so for 10 iterations):
For --single-timer:
```
Runtime: 3834491044
Runtime in seconds: 3.834491044
Visits: 52643690
Active: 0
Stopwatch frequency: 1000000000
```
For --timer:
```
[...]
flow_analysis.dart|_FlowAnalysisImpl.propertyGet: runtime: 818095151 (0.818095151 s), visits: 1328320, active: 0
flow_analysis.dart|FlowModel._updateVariableInfo: runtime: 827669322 (0.827669322 s), visits: 968180, active: 0
flow_analysis.dart|_FlowAnalysisImpl.variableRead: runtime: 1012755488 (1.012755488 s), visits: 1100140, active: 0
flow_analysis.dart|FlowModel.joinVariableInfo: runtime: 1118758076 (1.118758076 s), visits: 320810, active: 0
flow_analysis.dart|FlowModel.merge: runtime: 1185477853 (1.185477853 s), visits: 334100, active: 0
flow_analysis.dart|_FlowAnalysisImpl._merge: runtime: 1238735352 (1.238735352 s), visits: 334100, active: 0
```
Change-Id: Idaae6cdd2202b1a2d540da39db9aedb0c930329e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302280
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
For instance running like this:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --count
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
will now also print how often Constructors are executed, e.g. it contains
stuff like thid:
529,397: ast.dart|DartType.constructor:
715,197: ast.dart|Expression.constructor:
1,177,700: ast.dart|TreeNode.constructor:
2,001,460: ast.dart|Node.constructor:
Change-Id: I26ff69f8ad8a1453d6004e97952ce3b39bfff687
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When instrumenting one can use "--count" to instrument counting method
calls instead of instrumenting to create a flame graph.
From that I can for instance see that `Reference.node` is called 6+ mio
times when compiling compile.dart.
Example run:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --count
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill pkg/front_end/tool/_fasta/compile.dart
Change-Id: I583f4b53a474c3777bb059ea89d932607b7c23ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298100
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Could for instance be run like this:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates_subsequent.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
* The first command compiles and instruments "compile.dart" to record
all procedure calls.
* The second command runs the instrumented compiler on "compile.dart"
(but it could have compiled anything). Because every procedure is
instrumented this will take a lot longer than a usual run.
This produces a trace "cfe_compile_trace.txt" with every call taking
at least 1000 microseconds. This can be displayed via Chromes
about://tracing tool.
It also produces a file "cfe_compile_trace_candidates.txt" with a map
of the procedures that on average took at least 500 microseconds.
* The third command compiles and instruments "compile.dart", this time
only instrumenting the procedures mentioned in the map
"cfe_compile_trace_candidates.txt".
* The forth command runs the instrumented compiler on "compile.dart".
This run shouldn't take significantly longer than a non-instrumented
run. It produces a new "cfe_compile_trace.txt" which this time is
not filtered. It also produces a file
"cfe_compile_trace_candidates_subsequent.txt" of recorded procedures
that on average took at least 50 microseconds.
* The fifth and sixth commands repeats the third and forth but
instrumenting only the procedures mention in
"cfe_compile_trace_candidates_subsequent.txt".
The third iteration might not be needed, but if the first run was on a
smaller input (which it isn't in this example) there might be some calls
that on average took long enough to be included in the candidate list
because the first call was slow and there were only very few of them,
making the second trace very big because there are now a lot of - as it
turns out - very quick calls recorded. Adding the third iteration will
filter (at least some of) those out.
Change-Id: I702c5c9142e525502b02f37744fcdc9d2b0f9b20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296902
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Before this CL kernel tags had specialized tags that was marked by the
single high bit, then using the three lowest bits for a value:
128 + value = 0b10000xxx
136 + value = 0b10001xxx
144 + value = 0b10010xxx
So the numbers from 128 to 151 is taken by this scheme, but because of
the high bit marking stuff being special we can't really use 152-256.
This CL shifts the specialized tags up so it instead uses the 3 highest
bits as a marker while still using the lower 3 bits for the value:
224 + value = 0b11100xxx
232 + value = 0b11101xxx
240 + value = 0b11110xxx
This takes up 224-247 and leave 248-255 unused. It would let us use
128-223 though.
(If we eventually need more we can probably remove one of the
specialized ranges (SpecializedVariableSet isn't used very much in
previously sampled dill files) and use 4 bits for tagging).
Additionally, a tool to print free tags has been added (via binary.md),
and the "binary version is in sync with VM" test has been prepared
for version > 99.
TEST=Existing tests.
Change-Id: If77b12cee6fc3801628dd67dc40afbb018ec8a61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284302
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Right now the analyzer clears out the string canonicalization cache
after each file parse.
Similarly when the analyer serializes various information into
*.{unlinked2,linked,resolved} files & deserializes them again, it will
only have canonicalized strings per unit.
This means that strings that are common across compilation units will
exist many times in the heap, thereby increasing memory consumption of
the process.
This CL tries to avoid that by
* Using one string canonicalization cache across CFE & Analyzer
* Making the string canonicalization cache remember how often an entry
was used
* Pruning the cache instead of clearing it: We keep the most frequently
used elements while maintaining a cache that is <= 5 MB.
* Change analyzer code to use the string canonicalization in various
places to avoid many duplicate strings in the heap.
When running analyzer on flutter (and it's transitive code), the
analyzer itself has a heap of around 610 MB.
This CL reduces the memory consumed by strings from ~43 MB to ~33 MB
(~ 20 MB are alone dart source files which are unique). We do this at
the expensive of maintaining the string cache, which costs around 2 MB.
That leads to 8 MB of savings.
TEST=ci
Change-Id: Ic28d70492ab0d376e10714c7ecf2c258c790a022
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255245
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Paul Berry