LoadOptimizer has a builtin alias-analysis which recognized only
Redefinition and AssertAssignable as instructions which must
be followed through when traversing use lists for a given
definition. However after recent changes CheckNull should be
treated the same way as these other two instructions.
This lead to incorrect computation of aliasing identity and
consequently incorrect load forwarding.
This change fixes this bug and also changes implementation of
OriginalDefinition in a way that makes aliasing analysis code
more future-proof.
We introduce virtual method Definition::RedefinedValue and
reimplement Definition::OriginalDefinition through RedefinedValue.
Aliasing analysis is changed to use RedefinedValue to detect
if an instruction is a redefinition.
Fixes https://github.com/flutter/flutter/issues/30619
Bug: https://github.com/flutter/flutter/issues/30619
Change-Id: I8019c93779491a4e6f127119d1d56eb037a3bb56
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99170
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In general we would like to keep previous results of type propagation passes, however this
leads to situations where CompileType objects owned by definitions are cached as reaching
types at uses that are no longer directly connected to the definition itself.
This leads to situations when type propagator updates the type of the definition in place
via Definition::UpdateType, but does not enqueue an instruction which uses this type which
leads to incorrect fix-point computation.
As a fix we make the fact that some CompileType objects are owned by definitions explicit
by assigning [CompileType::owner_] field. Whenever we encounter situation that reaching type's
owner does not match current definition flowing into use we clone compile type to disconnect
it from original owner and prevent hidden mutation.
This CL also fixes two minor issues:
- incorrect computation of non-nullable type from a nullable CompileType with a cid;
- assings CompileType to LoadIndexedUnsafe instructions emitted by prologue builder;
Fixes https://github.com/dart-lang/sdk/issues/36156
Bug: 36156
Change-Id: I6536cfe1fda033cba3524336bfbdb871b88a8b3f
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-android-release-arm-try, vm-kernel-precomp-bare-linux-release-simarm-try, vm-kernel-precomp-bare-linux-release-simarm64-try, vm-kernel-precomp-bare-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-product-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98358
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This is the next step towards preventing compiler from directly peeking
into runtime and instead interact with runtime through a well defined
surface.
This CL decouples the hand-written intrinsifier code from the runtime:
* the intrinsifier is split up into a GraphIntrinsifier and AsmIntrinsifier
* the recognized methods list is moved to a separate .h file
* all intrinsifier code is moved into dart::compiler namespace
* the AsmIntrinsifier is only interacting with RT through runtime_api.h
Issue https://github.com/dart-lang/sdk/issues/31709
Change-Id: I0a73ad620e051dd49c9db7da3241212b3b74ccdd
Reviewed-on: https://dart-review.googlesource.com/c/92740
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
Rationale:
Rather than relying on a separate loop detector, rely
on the new loop framework, which avoids code duplication
and ensures any improvement in loop detection/handling
will benefit this phase too. Note, most of the time, the
same loops are discovered with a few exceptions (which
is okay, since this is "just" heuristic usage). This CL
also simplifies loop detection a bit.
https://github.com/dart-lang/sdk/issues/34473
Change-Id: I1a1b19b99a698c74822473d2a1fe370287c1ade4
Reviewed-on: https://dart-review.googlesource.com/c/80523
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Similar to how we treat catch entry instructions, this cl adds new
function and osr entry instructions. The [FunctionEntry] and
[OsrEntry] - just like [CatchBlockEntry] - have now their own initial
definitions. The [GraphEntry] has only initial definitions for
constants.
Explicit phis are inserted for all parameter / special parameter
instructions if necessary.
Future work is:
a) Minimize parallel moves due to the phis on parameters
b) Cleanup frame setup: Move it entirely into FunctionEntry/CatchEntry
(instead of the split version we have now)
Fixes https://github.com/dart-lang/sdk/issues/34435
Fixes https://github.com/dart-lang/sdk/issues/34287
Change-Id: Iefa0280a709716f748d6fb0523b8d0f4d8de1fec
Reviewed-on: https://dart-review.googlesource.com/c/74782
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Rationale:
Started a more structured implementation of detecting
loops and the loop hierarchy in the Dart flow graph.
This new framework can replace some of the more ad-hoc
approach taken now, as already started in this CL, and
also forms a foundation for more optimizations later.
https://github.com/dart-lang/sdk/issues/34473
Change-Id: I75130cb6863324910e3d068e4f2628c25fdf880c
Reviewed-on: https://dart-review.googlesource.com/c/79147
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Rationale:
(1) reset loop_info of block entries,
since recomputing on a modified graph
may encounter blocks that are no longer headers
(2) replaced O(n) linear scan over loop headers just
to test membership of the current block with
an O(1) test
(3) added some comments
https://github.com/dart-lang/sdk/issues/34473
Change-Id: I9e24a76bac9cf0225d8f1c996adfa6d82c175504
Reviewed-on: https://dart-review.googlesource.com/c/78703
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Previously we tried to rely on the assumption that all variables would be
boxed - so the machinery for setting correct catch-entry state only
supported tagged values and constants. However this both leads to worse code
and is not entirely correct assumption.
This also:
- renames various confusingly named classes: we move away from talking
about "catch entry state" to "catch entry moves" - because we only
record a subset of moves that needs to be performed and that does
not describe the whole state;
- refactors a bunch of associated code to be more readable and maintainable;
- adds documentation about catch implementation in optimized code
to runtime/docs/compiler;
Fixes https://github.com/flutter/flutter/issues/21685.
Change-Id: I03ae361a1bb7710acbd9f661ae014e663a163c59
Reviewed-on: https://dart-review.googlesource.com/74860
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Test Plan:
Will be tested by following revisions which introduce optimizations that invoke the
new entrypoint.
Change-Id: I56d714bceb92c44a13c46d52457154b82577aa8c
Cq-Include-Trybots: luci.dart.try:vm-kernel-win-release-x64-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/67345
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
After previous refactoring, StreamingScopeBuilder no longer depends on
StreamingFlowGraphBuilder.
This CL moves StreamingScopeBuilder to a separate file
vm/compiler/frontend/scope_builder{.h, .cc}.
Also:
* StreamingScopeBuilder is renamed to ScopeBuilder.
* IntMap is moved to hash_map.h.
* Minor cleanup of unused forward declarations and friend classes.
Change-Id: I5e780a53f37935c0a1d563d4fbaec3a92ae13d6a
Reviewed-on: https://dart-review.googlesource.com/63692
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Rationale:
Handles remaining polymorphic reason for typed_data
setters and getters (internal vs. external) during inlining.
Also introduces high level flow graph utilities that
can be reused throughout the compiler to reduce
future code duplication. Disables type speculation
for 64-bit AOT Dart2 to make all work.
Performance:
About 4x speedup on micro benchmarks (AOT64).
https://github.com/dart-lang/sdk/issues/33205
Change-Id: I678426719e49cd8aa1e5051523da12178120b3ba
Reviewed-on: https://dart-review.googlesource.com/59000
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
So far the frontend (parser, flow graph builder, ssa construction) were
aware of the actual frame layout.
This CL makes the indices we assign to [LocalVariable]s logical
indices, assigning:
* M parameters the indices 1 ... M
* N local variables the indices 0 -1 ... -(N-1)
The scope building, flow graph builder and ssa construction operate on
those logical indices.
When emitting actual code, the backend will translate those indices into
actual FP relative indices. This allows us to be more flexible in the
backend which frame layout we choose.
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: I9a504bf97821c257aafd2b3430df9f4c9da4b442
Reviewed-on: https://dart-review.googlesource.com/57321
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Passes bodies are moved into compiler_pass{.cc,.h}.
Invoking a pass is just INVOKE_PASS(Name) now, instead of putting a bunch of
if-s and calls in compiler.cc or precompiler.cc.
We also consolidate ability to print IL and enable-disable passes under a
single flag --compiler-passes, e.g.
--compiler-passes=-Inlining,-CSE disable inlining and CSE passes
--compiler-passes=Inlining+ print IL after Inlining pass and all
subsequent passes
Change-Id: I90ff54b04a54f20099f5bf38dd45b16b8e3c4781
Reviewed-on: https://dart-review.googlesource.com/43968
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
New folder structure (nested under vm/):
- compiler/
- jit/ - JIT specific code
- aot/ - AOT specific code
- backend/ - all middle-end and back-end code (IL, flow graph)
- assembler/ - assemblers and disassemblers
- frontend/ - front ends (AST -> IL, Kernel -> IL)
compiler/README.md would be the documentation root for the compiler
pipeline
Bug: https://github.com/dart-lang/sdk/issues/30575
Change-Id: I2dfd9688793bff737f7632ddc77fca766875ce36
Reviewed-on: https://dart-review.googlesource.com/2940
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Régis Crelier