Rationale:
With the switch to the new, "better", loop information,
we lost blocks that appear linearly in the "middle" of
loops. Such blocks want to move the split back to the
header, just like loop blocks, as further explained in
the code comments.
https://github.com/dart-lang/sdk/issues/34918
Change-Id: Iae10df51cae396c2c91c8a8478dbc674c4caebe9
Reviewed-on: https://dart-review.googlesource.com/c/84546
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Refactoring ddbe22190c
wrongly predicated usage of guarded_cid by use_field_guards flag.
However even though field guards are not in use in AOT mode we
still populate guarded_cid from the results of TFA inference.
This change restores pre-refactoring behavior and makes sure we
make use of information inferred by TFA.
Change-Id: I9929d32c763815504801e13c43326f80fd50687b
Reviewed-on: https://dart-review.googlesource.com/c/84633
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Make StoreIntanceField and LoadField instructions use a single uniform
abstraction: Slot (used to be called NativeFieldDesc), which represents
either a real Dart field (i.e. a field that has a corresponding Field object)
or a native VM field that does not have a corresponding Field object.
This refactoring eliminates raw stores/loads that were just using offsets
before - now we always know what kind of slots we are accessing and
this yields better aliasing information.
Change-Id: I2f48332d58258219565bd961764e8cc9dd4d75ce
Reviewed-on: https://dart-review.googlesource.com/c/74582
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit 2de63ac01c.
Reason for revert: This triggers shutdown deadlocks for some reason:
#0 0xf7782cd9 __kernel_vsyscall
#1 0xf7753d0b pthread_cond_wait@@GLIBC_2.3.2
#2 0x0108a515 dart::Monitor::WaitMicros(long long)
#3 0x0108a467 dart::Monitor::Wait(long long)
#4 0x00fe9048 dart::KernelIsolate::Shutdown()
#5 0x00f99ae4 dart::Dart::Cleanup()
#6 0x01278fce Dart_Cleanup
#7 0x00dd347e dart::bin::main(int, char**)
#8 0x00dd3d64 main
#9 0xf745caf3 __libc_start_main
#10 0x00dd2021 _start
TID 30443:
#0 0xf7782cd9 __kernel_vsyscall
#1 0xf7531ee6 epoll_wait
#2 0x00ddab61 dart::bin::EventHandlerImplementation::Poll(unsigned int)
#3 0x00dfb2d4 dart::bin::ThreadStart(void*)
#4 0xf774ff72 start_thread
#5 0xf753143e __clone
TID 30444:
#0 0xf7782cd9 __kernel_vsyscall
#1 0xf7753d0b pthread_cond_wait@@GLIBC_2.3.2
#2 0x0108a515 dart::Monitor::WaitMicros(long long)
#3 0x0108a467 dart::Monitor::Wait(long long)
#4 0x012484d8 dart::BackgroundCompiler::Run()
#5 0x01248a37 dart::BackgroundCompilerTask::Run()
#6 0x0112203a dart::ThreadPool::Worker::Loop()
#7 0x01121efe dart::ThreadPool::Worker::Main(unsigned int)
#8 0x01089e73 dart::ThreadStart(void*)
#9 0xf774ff72 start_thread
#10 0xf753143e __clone
Original change's description:
> [VM] Add @pragma annotations on Field, make @pragma annotations work generally
>
> Currently the @pramga('vm:exact-result-type') annotation only works if
> the function is a recognized method. This change changes that to make
> the VM just look if a function has the annotation (no matter if it's
> also in the list of recognized methods or not).
>
> Furthermore this CL adds a "has_pragma" bit to [Field] objects, similar
> to how we have it on [Function]/[Class]es. This allows annotating
> fields with types, as we do with function return types.
>
> Furthermore this CL lets the type propgagator use
> @pragma('vm:exact-result-type') annotations to narrow the [CompileType]
> set on [LoadFieldInstr]s.
>
> Since the @pragma is a general feature, this CL moves the
> `Function::FindPragma()` to `Library::FindPragma` (which is where any
> other metadata lookup happens). We also let the `FindPragma` accept any
> of Class/Function/Field objects.
>
> Furthermore this CL adds a bailout if we try to evaluate metadata in
> the background compiler, since the background compiler is not allowed
> to execute generated code. The bailout should trigger a re-compilation
> on the mutator thread.
>
> Furthermore the `FindPragma()` function is fixed to handle the case
> when the evaluation of the metadata results in e.g. a language error.
> In this case we simply claim to not have found a pragma annotation.
>
> Issue https://github.com/dart-lang/sdk/issues/31954
>
> Change-Id: I0900a80d5ae0f3e8d09baf13cba1b20dd974df31
> Reviewed-on: https://dart-review.googlesource.com/c/84037
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,kustermann@google.com,alexmarkov@google.com,sjindel@google.com
Change-Id: Ic0d22d32b0eea3a76ec245cabab0006f97ca1b05
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/84622
Reviewed-by: Martin Kustermann <kustermann@google.com>
Currently the @pramga('vm:exact-result-type') annotation only works if
the function is a recognized method. This change changes that to make
the VM just look if a function has the annotation (no matter if it's
also in the list of recognized methods or not).
Furthermore this CL adds a "has_pragma" bit to [Field] objects, similar
to how we have it on [Function]/[Class]es. This allows annotating
fields with types, as we do with function return types.
Furthermore this CL lets the type propgagator use
@pragma('vm:exact-result-type') annotations to narrow the [CompileType]
set on [LoadFieldInstr]s.
Since the @pragma is a general feature, this CL moves the
`Function::FindPragma()` to `Library::FindPragma` (which is where any
other metadata lookup happens). We also let the `FindPragma` accept any
of Class/Function/Field objects.
Furthermore this CL adds a bailout if we try to evaluate metadata in
the background compiler, since the background compiler is not allowed
to execute generated code. The bailout should trigger a re-compilation
on the mutator thread.
Furthermore the `FindPragma()` function is fixed to handle the case
when the evaluation of the metadata results in e.g. a language error.
In this case we simply claim to not have found a pragma annotation.
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: I0900a80d5ae0f3e8d09baf13cba1b20dd974df31
Reviewed-on: https://dart-review.googlesource.com/c/84037
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When strenghtening the types in AOT call specializer, we do it via redefinitions
instead of setting a reachingt type on the Value. This has the advantage that all
uses will get the new type, which improves e.g. StaticCall(_IntegerImpl.*, v1, v1)
where multiple uses can benefit.
This CL also changes the AOT call specializer to prefer equality comparisons over
strict comparisons, because strict comparisons can force boxing (which causes code bloat).
Change-Id: I803bb09c70ee2f4656062b5ce3cb28ffaf940e9b
Reviewed-on: https://dart-review.googlesource.com/c/84525
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
So far we had different optimization logic for int/double's depending on
whether they were [InstanceCallInstr]s or [StaticCalInstr]s.
The de-virtualization by TFA causes instance calls to be turned into static
calls which might cause different optimizations to apply.
This CL unifies the optimizations, so they are applied regardless of
whether the operation is an instance call or a static call.
Change-Id: Id4f229412e4d0f19835635bce8c9e5491cca8cb0
Reviewed-on: https://dart-review.googlesource.com/c/84433
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Rationale:
The more one knows about loops, the better!
This introduces a rigorous framework for detecting
induction variables (more precise "sequence" variables).
Even though this is already pretty general, in the
future we can expand this on a "need to" base, recognizing
more operators (shifts, negate, etc.) and more classes
of induction (perhaps geometric, polynomial, etc.).
Change-Id: I82a14515e8ae946d520ee470cd31046f6a58af7d
Reviewed-on: https://dart-review.googlesource.com/c/81743
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This is especially important for multiple entry-points in AOT mode, since without the type
information we can't inline certain intrinsics (because they would have to de-opt).
Change-Id: I62352234c95a1211ff7cdabb9cefc48990427a6f
Reviewed-on: https://dart-review.googlesource.com/c/82999
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
- Remove dead Isolate::IsTopLevelParsing.
- Remove dead TraceFunctionEntry/Exit.
- Migrate more tracing flags to flag_list.h to allow code elimination in non-debug modes.
- Require an explicit Zone parameter for CheckedHandles.
- Remove side-effects from RuntimeEntry constructor.
out/ProductX64/exe.stripped/dart_precompiled_runtime 4063464 -> 4046952 (-16k)
Change-Id: Iffd3de25a03d2354cdecf2d79aa761c33ab08bd3
Reviewed-on: https://dart-review.googlesource.com/c/83120
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This frees the name Bytecode that will become the name of a new VM class.
Class Code will only refer to compiled code and Bytecode will refer to kernel
bytecode.
Change-Id: If64a5d688f0bf75220e67ef2932f4141782e9dc3
Reviewed-on: https://dart-review.googlesource.com/c/82703
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
On a Flutter app scrolling through a large table running on a Moto G 4, max pause time reduces from 129ms to 52ms.
Before
6-44ms CollectNewGeneration
118-129ms CollectOldGeneration
After
6-52ms CollectNewGeneration
3-10ms StartConcurrentMarking
20-42ms CollectOldGeneration (i.e., finalize marking)
Code size increases on Flutter Gallery:
ARM32 Instructions(CodeSize): 5772688 -> 5968624 (+3.39%)
ARM64 Instructions(CodeSize): 6082400 -> 6251008 (+2.77%)
Bug: https://github.com/dart-lang/sdk/issues/34002
Change-Id: Iac9a0b3d91b497b5016c4f89e8779c488f105a5b
Reviewed-on: https://dart-review.googlesource.com/c/76780
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Threads in the native or blocked states don't prevent safepoints, so they may run concurrently with a safepoint operation like GC. It is not safe for handles to be allocated while the GC is visiting them, so these threads must not allocate handles. Assert only threads in the VM or generated states, which prevent safepoints until they check in, may allocate handles. (Generated code does not allocate handles, but leaf runtime entries remain in the generated state.)
Bug: https://github.com/dart-lang/sdk/issues/34883
Change-Id: I1a211778f7ef96b53a2405f0ee9dde7871b122b6
Reviewed-on: https://dart-review.googlesource.com/c/81540
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit 0170b8d529.
Reason for revert:
The underlying problem has been fixed.
Original change's description:
> Revert "[vm/compiler] Use loop framework for AOT inline heuristics"
>
> This reverts commit daae20d32e.
>
> Reason for revert:
>
> The kernel-precomp bots are seeing this error:
>
> ../../runtime/vm/object.h: 3134: error: Handle check failed: saw 2249186640 expected Function
>
> Not sure what that is yet, but reverting to get bots green again while I investigate.
>
>
> Original change's description:
> > [vm/compiler] Use loop framework for AOT inline heuristics
> >
> > Rationale:
> > Without proper execution counters, the inline AOT inliner
> > marks every call site "cold", effectively disabling inlining
> > altogether. This change introduces loop-based static heuristic
> > that assumes statements nested inside loops are executed more
> > frequently. This results in more inlining.
> >
> > Note:
> > Conservative version is used for now which yields
> > more performance without increasing code size too much.
> > There is still a lot of performance left at the table
> > which we could exploit if we fine tune heuristics
> > regarding code size.
> >
> > Bug:
> > https://github.com/dart-lang/sdk/issues/34473
> > https://github.com/dart-lang/sdk/issues/32167
> >
> >
> > Change-Id: I86ba60f93bdab363cd22ab6bdbcf6688f2042fea
> > Reviewed-on: https://dart-review.googlesource.com/c/81187
> > Commit-Queue: Aart Bik <ajcbik@google.com>
> > Reviewed-by: Alexander Markov <alexmarkov@google.com>
>
> TBR=vegorov@google.com,alexmarkov@google.com,ajcbik@google.com
>
> Change-Id: If5ca82966966ebef4ec0b4e921515d23f6bd492b
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://dart-review.googlesource.com/c/81335
> Reviewed-by: Aart Bik <ajcbik@google.com>
> Commit-Queue: Aart Bik <ajcbik@google.com>
TBR=vegorov@google.com,alexmarkov@google.com,ajcbik@google.com
Change-Id: I8c160f59f8e91782f235cbcea607aef4227963f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/81500
Reviewed-by: Aart Bik <ajcbik@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
This reverts commit daae20d32e.
Reason for revert:
The kernel-precomp bots are seeing this error:
../../runtime/vm/object.h: 3134: error: Handle check failed: saw 2249186640 expected Function
Not sure what that is yet, but reverting to get bots green again while I investigate.
Original change's description:
> [vm/compiler] Use loop framework for AOT inline heuristics
>
> Rationale:
> Without proper execution counters, the inline AOT inliner
> marks every call site "cold", effectively disabling inlining
> altogether. This change introduces loop-based static heuristic
> that assumes statements nested inside loops are executed more
> frequently. This results in more inlining.
>
> Note:
> Conservative version is used for now which yields
> more performance without increasing code size too much.
> There is still a lot of performance left at the table
> which we could exploit if we fine tune heuristics
> regarding code size.
>
> Bug:
> https://github.com/dart-lang/sdk/issues/34473
> https://github.com/dart-lang/sdk/issues/32167
>
>
> Change-Id: I86ba60f93bdab363cd22ab6bdbcf6688f2042fea
> Reviewed-on: https://dart-review.googlesource.com/c/81187
> Commit-Queue: Aart Bik <ajcbik@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
TBR=vegorov@google.com,alexmarkov@google.com,ajcbik@google.com
Change-Id: If5ca82966966ebef4ec0b4e921515d23f6bd492b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/81335
Reviewed-by: Aart Bik <ajcbik@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Rationale:
Without proper execution counters, the inline AOT inliner
marks every call site "cold", effectively disabling inlining
altogether. This change introduces loop-based static heuristic
that assumes statements nested inside loops are executed more
frequently. This results in more inlining.
Note:
Conservative version is used for now which yields
more performance without increasing code size too much.
There is still a lot of performance left at the table
which we could exploit if we fine tune heuristics
regarding code size.
Bug:
https://github.com/dart-lang/sdk/issues/34473https://github.com/dart-lang/sdk/issues/32167
Change-Id: I86ba60f93bdab363cd22ab6bdbcf6688f2042fea
Reviewed-on: https://dart-review.googlesource.com/c/81187
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This is a reland of 6ba3e55ecc
The issue was that SlowTypeTestStub used in precompiled mode did not handle a
Smi instance before calling the Subtype2TestCache stub which does not support
it. See PatchSet 2 for the fix.
Is there a more efficient solution?
Original change's description:
> [VM runtime] Support Smi instances in type test cache.
>
> This adds SubtypeTestCache-based optimizations for type tests against
> * dst_type = FutureOr<T> (when T=int/num)
> * dst_type = T (when T = FutureOr<int/num>)
>
> Remove dangerous LoadClass pseudo assembler instruction (does not work for Smi).
> Handle instantiated void in type tests (along with dynamic and Object).
>
> Change-Id: I0df0fc72ff173b9464d16cc971969132b055a429
> Reviewed-on: https://dart-review.googlesource.com/c/81182
> Commit-Queue: Régis Crelier <regis@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: I333ca47aebd7f0b663059ab6afc5d1cd8d7d5210
Reviewed-on: https://dart-review.googlesource.com/c/81320
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This adds SubtypeTestCache-based optimizations for type tests against
* dst_type = FutureOr<T> (when T=int/num)
* dst_type = T (when T = FutureOr<int/num>)
Remove dangerous LoadClass pseudo assembler instruction (does not work for Smi).
Handle instantiated void in type tests (along with dynamic and Object).
Change-Id: I0df0fc72ff173b9464d16cc971969132b055a429
Reviewed-on: https://dart-review.googlesource.com/c/81182
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@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>
Velocity tracker is improved by 2.1%.
Flutter gallery code size is regressed by 0.9%
Golem benchmarks are a wash, because they use dynamic calls very aggressively in ways
uncharacteristic of Dart 2 code.
Change-Id: Id9e248f7c15ea6a8f69be2a4bbc0e4fc64a8c188
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/c/79242
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Samir Jindel <sjindel@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>
Aart Bik