On the otherwise path it was producing a block that ended with a call. Such IR
is invalid because blocks can only end with control flow instructions, like
Branch, Goto, Return or Throw.
Bug:
Change-Id: I67971fba00c01f1e063ac584abfa6aec2ea376d9
Reviewed-on: https://dart-review.googlesource.com/19004
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
It appears like the manual flow graph building code for
MethodRecognizer::kObjectRuntimeType is wrong and was exposed by
enabling it recently.
Change-Id: Ia4be8c4bc7c3342e0cdf1cb8b270dc48b5f2fde4
Reviewed-on: https://dart-review.googlesource.com/17920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Now that we do eager rehashing of linked hashmaps we no longer have the
index field be `null` (which in the past signaled we needed rehashing).
This means we can teach the optimizer that loads from the index fied
always result in kTypedDataUint32ArrayCid.
Change-Id: Ic012881c12b2310a6337696521fa1355afd4069f
Reviewed-on: https://dart-review.googlesource.com/17447
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Previously we would sometimes build specifically hand-crafted flow graph
code for recognized methods and sometimes let the normal flow graph
builder do it (depending on whether inlining was triggered via
[CallSiteInliner] or [CallSpecializer]).
This CL makes us use the hand-crafted flow graph building for recognized
methods in both cases.
Change-Id: I58405b16adca810fd7ccff32027b9d4a13858976
Reviewed-on: https://dart-review.googlesource.com/17445
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This change brings down core snapshot size by ~750KB, and brings
down app-jit snapshot size of simple "Hello, World" dart script by
~650KB. The bot cycle times will also come down by around ~20%.
Change-Id: I2a01c98bedc7ebfa2a653983995486a71504daf3
Reviewed-on: https://dart-review.googlesource.com/16323
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This improves
* JIT performance by around 14%
* precompiled performance by around 2%
on a simple map microbenchmark.
Change-Id: I623e2a715a709f89f2514ae30fbb504ee2e31661
Reviewed-on: https://dart-review.googlesource.com/17165
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
CloneContext is implemented as a runtime call so it is considerably slower
than AllocateContext which leads to performance issues in loops that capture
iteration variables in for loops.
Lowering CloneContext into AllocateUninitializedContext and a sequence of
explicit load&store instructions both improves the performance by avoiding
the runtime call and also makes CloneContext semantics exposed to store-load
forwarding and allocation sinking.
PutIfAbsent benchmark from issue #31113 is improved by 5x, while
ForInGeneratedLoop benchmark is improved by 8x.
Bug: https://github.com/dart-lang/sdk/issues/31113
Change-Id: I03fdede75f1a85fda92487aa8f9307ce06f23903
Reviewed-on: https://dart-review.googlesource.com/16280
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Currently, the Kernel FE doesn't set up parent pointers correctly for
signature function types. This prevents type parameters on generic
function types from being finalized correctly. In addition, finalization
of generic interface types within a generic function type can crash if they
reference not-yet-finalized type parameters of the enclosing function type.
This review solves both issues. Several failing tests pass again, although
more thorough testing is blocked on Github issue #31213 (nested generic function
types crashing in Fasta).
Bug:
Change-Id: Ib5ee6b2566492e3fd6688fe5a6b6976692562ea1
Reviewed-on: https://dart-review.googlesource.com/16360
Reviewed-by: Régis Crelier <regis@google.com>
Currently, we have some tests that run with reified generic functions ON and
some with it OFF. However, this causes inconsistencies when running the Kernel
FE from snapshot in the VM, since the VM requires that the flag be consistent
with the snapshot. Our solution is to turn the reified generic functions flag
into a per-isolate flag, which is always disabled in the Kernel FE's isolate.
Bug:
Change-Id: Ia91e9f0ff5fc059edf4bdbd79ef14abb288b4a49
Reviewed-on: https://dart-review.googlesource.com/16020
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL improves performance of allocation statistic counters on ARM
by removing duplicated loads and increasing distance between dependent
loads. These statistic counters are part of allocator fast path in a
non-product mode.
This change improves performance of gestures/velocity_tracker_bench
Flutter micro-benchmark in 'flutter run --profile' mode:
Before: 3352 µs
After: 3156 µs (-5.8%)
(minimum of 5 runs)
Change-Id: Ic7998318d9ca3e7997379d0054faaf5b0b569bb6
Reviewed-on: https://dart-review.googlesource.com/15640
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This new object points to program wide data like string offsets,
string data etc. It also holds an array of pointers to all Script
objects corresponding scripts in the program's source table.
This new object type is required for two reasons:
1. The Script objects now have a number of fields which point to
program wide data. All Script objects point to the same data in the
VM heap. By introducing an indirection via this new object, we reduce
the number of pointers in Script objects.
2. Lazy loading of VM objects - Kernel nodes of
entities like fields and functions have a field which point to the
source file in which they are defined. This entry is an index into
the program wide source table and helps in associating
functions/fields with their actual source location. When lazy loading
functions and fields, the pre-loaded script objects in the
program's KernelProgramInfo help in associating the functions and
fields with the correct source script at load time.
Change-Id: Id863284ae7dd98b0832e5dfc115dabad1ed762d8
Reviewed-on: https://dart-review.googlesource.com/13920
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This flag indicates when a procedure's return type makes contravariant
use of a class type parameter. The front end will have to insert "as"
checks at any call sites that refer to such a procedure as their
interface target. Placing the flag on the procedure will allow the
front end to determine whether the check is needed once, at the same
time as it's determining the need for covariant parameter checks,
rather than when compiling individual call sites.
Once this lands I will follow up with CLs that cause the front end to
set the flag appropriately, and to generate the necessary "as" checks.
Change-Id: I989fc702bc233384eb5ea8cd630c8efd384ab248
Reviewed-on: https://dart-review.googlesource.com/14365
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Such a call site starts with a reference to a stub in the VM isolate, so the pointer was not recordered, but after it first runs it will be patched to a code object in the current isolate, which may move during compaction.
Bug: https://github.com/dart-lang/sdk/issues/30978
Change-Id: I3bf8fd1cf8884cbba9956254cad70f46e8b8cc00
Reviewed-on: https://dart-review.googlesource.com/12701
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously, a lot of recognized instance methods were inlined
only if they are called using InstanceCall instruction.
This CL enables inlining of such methods even if they are called
using StaticCall instruction. Such static calls may appear as the
result of devirtualization of instance calls.
Fixes slow-down of Flutter gestures/velocity_tracker benchmark when
devirtualization is enabled without --experimental-strong-mode.
(The slow-down was caused by inline heuristics rejecting to inline
several methods as their speculative bodies contain non-inlined
calls to recognized methods.)
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: Id0ec0669d0e3fe05aa708baec4a468892dbe7f8e
Reviewed-on: https://dart-review.googlesource.com/13200
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL optimizes Type.hashCode similarly to String.hashCode, by
introducing intrinsic version of hashCode calculation which uses
hashcode stored in Type instance.
This is important for Flutter's .of pattern, which heavily uses
Maps with Type keys.
Results on Flutter stocks/build_bench.dart microbenchmark:
Before: 4906 µs
After: 4751 µs
(minimum of 5 runs, using tip of Flutter and Flutter engine)
Issue: https://github.com/dart-lang/sdk/issues/31011
Issue: https://github.com/flutter/flutter/issues/11572
Change-Id: Ifbaf721050007db49bbd969dc669d070f4ce839e
Reviewed-on: https://dart-review.googlesource.com/12622
Reviewed-by: Zach Anderson <zra@google.com>
Devirtualization optimization now adds metadata to kernel AST instead
of transforming nodes to Direct* ones. The direct call metadata
provides information about checking receiver for null, while
Direct* kernel nodes do not support null checking.
VM's kernel binary loader is extended to extract arbitrary metadata
from kernel binaries and keep it for flow graph builder.
Kernel flow graph builder is extended to take direct call metadata
into account and generate CheckNull/StaticCall instructions
for devirtualized PropertyGet, PropertySet and MethodInvocation nodes.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I57f56fbf4a8981d33b1571c0d93105cf8ca71d76
Reviewed-on: https://dart-review.googlesource.com/12260
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Before this change, each function and field had its own kernel data blob
in the VM heap. With this change, the entire kernel data of a library is
stored as one single blob in the VM heap. Functions and fields store an
offset which points to the kernel data, specific to them, in that single
blob.
The pointer to the kernel data for a library is saved in two places:
1. With the library objects themselves.
2. With all the patch classes of the library.
3. With the patch classes created during hot reload.
Change-Id: Ie03e738c4d20f16056a5ef04341b75506fda9c60
Bug:
Reviewed-on: https://dart-review.googlesource.com/6601
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
When precompiling we might trigger optimizing compilation eagerly
so constant evaluation did not have a chance to run.
It is totally fine though because precompiler does not use
background thread.
Bug:
Change-Id: I6e889284d9ef9be8b09c6f4fe7695c82a78bcee4
Reviewed-on: https://dart-review.googlesource.com/12280
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Alexander Markov