* when building IL from Kernel use canonical double representation
instead of allocating new double objects;
* in constant propagation canonicalize immutable primitive constants
(strings, mints and doubles) before replacing instruction with its
constant value;
This relands 5909932d38 with the part
that was causing timeouts on flutter_test reverted.
See https://github.com/dart-lang/sdk/issues/32904 for more details.
TBR=aam@google.com
Change-Id: I0c128e44dd6c9689c4b7e9dd91832408214847f3
Reviewed-on: https://dart-review.googlesource.com/51460
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Original revision is in Patchset 1.
Run against failing kernel-precomp tests in "cl-linux-try".
Change-Id: I997de294150ef7dd0874eeccb8b6187ae64ea813
Reviewed-on: https://dart-review.googlesource.com/51220
Reviewed-by: Erik Corry <erikcorry@google.com>
* when building IL from Kernel use canonical double representation
instead of allocating new double objects;
* in constant propagation canonicalize immutable primitive constants
(strings, mints and doubles) before replacing instruction with its
constant value;
Change-Id: I18a99c1ec5cddf4de4ea0571352408bd34faeb38
Reviewed-on: https://dart-review.googlesource.com/50728
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
We add two things:
* --print_instruction_stats makes compiler dump per IL instruction size
breakdown (how many bytes of code were produced from specific instruction
kinds). This was largely implemented by kustermann@ in
https://codereview.chromium.org/2584613002/ and this CL does only few changes
to the original implementation, namely more uniform handling of slow-path code
and puts statistics object into RawInstructions (which has free space due to
alignment) instead of RawCode.
* --print_instructions_sizes_to=symbols.json makes compiler dump per Instruction
object size breakdown into a JSON file. This JSON file can later be processed
with pkg/vm/tool/run_binary_size_analysis.dart script to produce interactive
binary size diagram similar to runtime/third_party/binary_size tool.
Change-Id: Ied4965b9a0a91b3025eefbe981ecd47cdcf782d6
Reviewed-on: https://dart-review.googlesource.com/50501
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
It complicates the intermediate language, none of the back ends are
using it, and it's not something that we want transformation writers
and code generators to deal with.
Change-Id: Ic79f7935dd8619bd233346bb25947e864f38a104
Reviewed-on: https://dart-review.googlesource.com/50440
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
Before, the part-URI was serialized as a file-URI and conflated with
source location information. The part-URI is the URI in the following
declaration in a Dart source file:
part "URI";
This is different from what we normally call a file-URI. A file URI
is used to point to the source location of the part declaration, not
the URI in the part declaration.
Furthermore, the field was serialized using writeUriReference which
only works for URIs that are in the uriToSource map on a Component.
Although this might seem like a safe optimization, it doesn't work
if the uriToSource map is omitted or if a part declaration refers to
a missing file.
Finally, due to the confusing use of fileUri, LibraryPart was
mistakenly implementing FileUriNode and annotations were stripped
of source locations if the source for the part were omitted from
uriToSource.
The partUri field is now an unresolved string that can be resolved
against either the parent library's import- or file-URI to obtain
either version as needed.
Change-Id: I255cb4eeaf89928292ab32a2f6be9ead6cc8cee1
Reviewed-on: https://dart-review.googlesource.com/49500
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Made modifications to the original VM flow graph builder so the token
position for the top frame of the overflow stack is the same as the
token position of the method (before we pointed to the opening '{' or
'=>').
Change-Id: I5c878fc238898e2fea197ea80ed4e320adca9439
Reviewed-on: https://dart-review.googlesource.com/48448
Reviewed-by: Alexander Markov <alexmarkov@google.com>
You can't use it in a way that would require Phi in the SSA form
because SSA construction does not support generating phi-functions
for the expression stack.
Change-Id: I57a029412cbdd796ecfd3cdbd0ec68e0dbca2356
Reviewed-on: https://dart-review.googlesource.com/47740
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The source-based pipeline was simply iterating the token script of a
[Script] to generate a list of (line, [token positions]) tuples.
The kernel-based pipeline is not based on the source (and therefore also
not based on the token stream). Instead it's based on information from
two places:
a) The .dill file constains a delta-encoded list of line start file
offsets. This line starts array is attached to [Script] objects via
[RawScript.line_starts_].
b) It scans the *entire* isolate's program structure (i.e. libraries,
classes, functions and fields) and does abstract interpretation
of the kernel blob (ast) and saves the encountered token positions
on the side. Afterwards the token positions are merged together
with the line-starts from a) which then produces the list of (line,
token positions) tuples.
This CL changes b) to only do the abstract interpretation of
functions/fields which are relevant for the [Script] we are generating
the list of (line, [token position]) tuples for.
Nonetheless, b) will still iterate over the entire isolate's program
structure to find all possible elements belonging to a specific
[Script]. This is a separate issue which should be handled.
On one example it reduces time to get the coverage from ~ 35 seconds to 9.5
seconds (baseline from dart-v1 is around 6.5 seconds).
Issue https://github.com/dart-lang/sdk/issues/32562
Change-Id: I64cda28666c732938379cdf4b2ac62a2371cb3b7
Reviewed-on: https://dart-review.googlesource.com/47080
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Translate assert statements in async functions. The translation of
the condition subexpression can produce a sequence of statements that
have been hoisted out of it. These need to be guarded so they are
executed only when asserts are enabled.
For this purpose, we introduce an AssertBlock. The semantics of the
assert block:
assert { s0; ...; sn; }
is the same as:
if (assertsEnabled) { s0; ...; sn; }
where assertsEnabled is a more primitive nullary expression that is
true iff. assertions are enabled. We chose not to encode this using a
construct like assertsEnabled because (1) we would have to support it
appearing as an arbitrary expression which we don't currently need
and (2) it requires deeper pattern matching to detect and skip the
guarded code when desired.
The translation is more complicated because if there is a message
subexpression in an assert, it is conditionally evaluated only if the
assert's condition is false.
Fixes https://github.com/dart-lang/sdk/issues/28498
Change-Id: I0912a57104ede3160533e49f65b6fb79b76f1500
Reviewed-on: https://dart-review.googlesource.com/46442
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL changes:
* package:kernel/clone.dart: To not clone file offsets if the
file-uri we copy from is unknown.
* package:kernel/binary/ast_to_binary.dart: To not write out file
offsets if the file-uri is not written/indexed (which happens if
the file uri is not in the `Program.uriToSource` map).
* It reverts the file renaming part of 60a2cfa219 which
fixed the name collision problem only partially (it missed to
rename `runtime/lib/double.dart`, which is not possible because
there's already a `double_patch.dart` file).
Instead of renaming, we solve the problem by mangling the names as follows:
.../sdk/lib/core/double.dart -> dart:core/double.dart
.../runtime/lib/double.dart -> dart:core/runtime/lib/double.dart
.../runtime/lib/double_patch.dart -> dart:core/runtime/lib/double_patch.dart
* It changes the test to ignore any negative token positions. The vm
service does not just expose `-1` token positions for places where
there is no source, but also e.g. `-9` (which means TokenPosition::kMethodExtractor),
this was one reason why the appjit test failed.
* It changes the test to try to force-compile everything (unsure if that works).
Issue https://github.com/dart-lang/sdk/issues/32489
Change-Id: Ia9f42ca9d56d987e3041175add549bb7a133f269
Reviewed-on: https://dart-review.googlesource.com/46341
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This simplifies figuring out what went wrong from just
debugging output in some cases.
Change-Id: Ie7a775c57fb691d6bd3ca1c70a04fb6cbe9e0875
Reviewed-on: https://dart-review.googlesource.com/43060
Reviewed-by: Jens Johansen <jensj@google.com>
This reverts commit 52d1b4e96d.
Reason for revert: Analyzer and DDC do not support the super-mixin fix and flag, so the new test fails on them. The test needs to either be marked as failing on them, or support needs to be added and work in the test framework.
Original change's description:
> Fix a bug in Kernel's mixin elimination
>
> Mixin elimination copied factory constructors from the mixin class to
> the mixin application class. This could be observed as an unbound
> type parameter which led to a crash in the VM. Fixes
> https://github.com/dart-lang/sdk/issues/32267.
>
> Change-Id: I87b70a35d11c364739d01e261adf5329d492d8cf
> Reviewed-on: https://dart-review.googlesource.com/42922
> Reviewed-by: Jens Johansen <jensj@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,jensj@google.com,kmillikin@google.com
Change-Id: I4a0bcf0b323c9adef7e5dc7d9019b6aafe40509d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/42960
Reviewed-by: William Hesse <whesse@google.com>
This reverts commit ef51b33f22.
Reason for revert: Issue from initial land was fixed in 076db33f03.
Original change's description:
> Revert "[kernel] Don't always treat doubles as constants"
>
> This reverts commit 12407c3ea0.
>
> Reason for revert: co19/Language/Expressions/Object_Identity/double_t01 fails in -c dartkp -r dart_precompiled mode.
>
> Original change's description:
> > [kernel] Don't always treat doubles as constants
> >
> > Previously, when the VM parsed a doubles from the dill file it passed
> > control over to the constant evaluator which would then case the
> > value and canonicalize it.
> > That doesn't really seem to make sense when its not used in a const
> > context, nor is it done the same way for integers for instance.
> >
> > This CL changes that and treats doubles the same way as integers.
> >
> > Below timings are statistics run through "ministat" based on 5 runs
> > of each configuration (now and before). The timings is for running
> > the dill file with the VM, i.e. the dill file was precompiled via
> > fasta.
> >
> > Program adding 50,000 doubles to a list and prints the last one:
> >
> > -56.6 +/- 28.2389
> > -10.9988% +/- 5.48753%
> > (~510 ms -> ~460 ms)
> >
> > Program adding 1,000,000 doubles to a list and prints the last one:
> >
> > -3177.2 +/- 263.54
> > -31.4643% +/- 2.60987%
> > (~10 seconds -> ~7 seconds)
> >
> > Hello world program:
> >
> > No difference proven at 95.0% confidence
> >
> > Change-Id: I7dd748e759b3e433bc806b2ef2505d29f0b109b6
> > Reviewed-on: https://dart-review.googlesource.com/42000
> > Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
> > Commit-Queue: Jens Johansen <jensj@google.com>
>
> TBR=ahe@google.com,vegorov@google.com,jensj@google.com
>
> Change-Id: If8efa9917c009f2df68a3ef00331ab45bf8bf67b
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://dart-review.googlesource.com/41981
> Reviewed-by: Jens Johansen <jensj@google.com>
> Commit-Queue: Jens Johansen <jensj@google.com>
TBR=ahe@google.com,vegorov@google.com,jensj@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I3c20797f585057e8f77e917918926dcfa921df0a
Reviewed-on: https://dart-review.googlesource.com/42720
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Under certain conditions front-end currently generates as{TypeError}
type checks in constant expressions. Support evaluating these type
checks as constant expressions instead of rejecting them.
Change-Id: Id432c4c5062d7bab89c29fef308b42b2cbd64de8
Reviewed-on: https://dart-review.googlesource.com/41761
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit 12407c3ea0.
Reason for revert: co19/Language/Expressions/Object_Identity/double_t01 fails in -c dartkp -r dart_precompiled mode.
Original change's description:
> [kernel] Don't always treat doubles as constants
>
> Previously, when the VM parsed a doubles from the dill file it passed
> control over to the constant evaluator which would then case the
> value and canonicalize it.
> That doesn't really seem to make sense when its not used in a const
> context, nor is it done the same way for integers for instance.
>
> This CL changes that and treats doubles the same way as integers.
>
> Below timings are statistics run through "ministat" based on 5 runs
> of each configuration (now and before). The timings is for running
> the dill file with the VM, i.e. the dill file was precompiled via
> fasta.
>
> Program adding 50,000 doubles to a list and prints the last one:
>
> -56.6 +/- 28.2389
> -10.9988% +/- 5.48753%
> (~510 ms -> ~460 ms)
>
> Program adding 1,000,000 doubles to a list and prints the last one:
>
> -3177.2 +/- 263.54
> -31.4643% +/- 2.60987%
> (~10 seconds -> ~7 seconds)
>
> Hello world program:
>
> No difference proven at 95.0% confidence
>
> Change-Id: I7dd748e759b3e433bc806b2ef2505d29f0b109b6
> Reviewed-on: https://dart-review.googlesource.com/42000
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
> Commit-Queue: Jens Johansen <jensj@google.com>
TBR=ahe@google.com,vegorov@google.com,jensj@google.com
Change-Id: If8efa9917c009f2df68a3ef00331ab45bf8bf67b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/41981
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously, when the VM parsed a doubles from the dill file it passed
control over to the constant evaluator which would then case the
value and canonicalize it.
That doesn't really seem to make sense when its not used in a const
context, nor is it done the same way for integers for instance.
This CL changes that and treats doubles the same way as integers.
Below timings are statistics run through "ministat" based on 5 runs
of each configuration (now and before). The timings is for running
the dill file with the VM, i.e. the dill file was precompiled via
fasta.
Program adding 50,000 doubles to a list and prints the last one:
-56.6 +/- 28.2389
-10.9988% +/- 5.48753%
(~510 ms -> ~460 ms)
Program adding 1,000,000 doubles to a list and prints the last one:
-3177.2 +/- 263.54
-31.4643% +/- 2.60987%
(~10 seconds -> ~7 seconds)
Hello world program:
No difference proven at 95.0% confidence
Change-Id: I7dd748e759b3e433bc806b2ef2505d29f0b109b6
Reviewed-on: https://dart-review.googlesource.com/42000
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The list of recognized methods in the VM includes information about
result type. If there is no known/concrete result cid, the list
contains dynamic. When StaticCallInstr for recognized method is created,
its result type was pulled from the list even if it was dynamic.
This change avoids setting result type to dynamic in such case
and fixes the assertion for conflicting result types from the list of
recognized methods and from global type inference.
Now, if list of recognized methods has dynamic, and inferred type
is available, the latter will be used.
Change-Id: I7da7313f93ca08a142226026a4645124c30cfd8f
Reviewed-on: https://dart-review.googlesource.com/41080
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Vyacheslav Egorov