This way, users of S-expression deserialization will not also pull in
the rest of the upcoming IL deserialization functionality (and
anything extra needed by that).
Also changes SExpParser::ReportError to just print the error
information to stderr and abort, instead of using the Dart VM
exception machinery.
Change-Id: Id01b2a6fdca1a6204d502f398df139c2faa12d07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111644
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Teagan Strickland <sstrickl@google.com>
* Add a new `SExpDouble` atom and change `SExpNumber` to `SExpInteger`.
* Allow for negative integers in deserialization.
* Add support for `LocalVariable`s and related instructions.
* Function objects are now represented by actual S-expressions generated
with the new `FunctionToSExp` method. Previously, they were only represented
by a symbol containing their canonical name.
* The top-level tag for a serialized flow graph is now `FlowGraph`, not
`function`. This avoids confusion between serialized flow graphs and
serialized function references. Similarly, the old `FunctionToSExp`
method is now called `FlowGraphToSExp`.
* Made all SExpression* returning functions that take Object (or subclass)
instances return nullptr if the passed in instance is the null object,
except for ObjectToSExp, which returns the symbol `null`.
* Factored out creating tags for the different kind of block/function
entry and also created an `Entries` section to the top-level `FlowGraph`
form that contains function entry points similar to the `Constants` one
instead of inlining entries as separate elements in the `FlowGraph` form.
* Additional extra information in verbose mode for some elements.
Bug: https://github.com/dart-lang/sdk/issues/36882
Change-Id: Iede3865ec64f81955a87fd57b10e74d49ee8414c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110917
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Rationale:
The attached test, a simplified version from a case found
by fuzzing, yielded the range [4,4] for the left hand side
of the division but [25,0] (sic!) for the right hand side.
This reverse range caused the logic in the TRUNC evaluation
to pass the >= 1 test but introduce the division by zero
in the compiler code. The true culprit, however, was
the reason for [25,0] which was due to a difference
in C++ and Dart shift right semantics. This CL fixes
the bug and adds some sanity assert to find more of
such cases.
https://github.com/dart-lang/sdk/issues/37622
Change-Id: I60e07428435d99589e1177c113ef5e24e1611d0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110420
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
AssertAssignable::ComputeType used to compute an intersection type
between cid available in the type of the value and abstract destination
type. This lead to creation of confusing impossible types like
{cid: kDoubleCid, type: int} and lead to problems in subsequent optimization
passes.
Fixes https://github.com/flutter/flutter/issues/35613
Change-Id: I9662c2dd0deaabbbb73ddde30cc4ee32235bad67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108276
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Move generation of Function objects for native trampolines to the Precompiler, so they can be generated during AOT and tree-shaken if possible.
Issue dartbug.com/35765
Change-Id: I0e69b7e0b22db73e3a40f2fe445660e57ddb6fa9
Cq-Include-Trybots: luci.dart.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-dartkb-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107407
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Instead, we set a bit on force-optimized code so that deoptimization knows to skip it and exception
handling will execute catch-entry moves.
In addition we don't throw away deoptimization info for these codes, so that exception handling
works.
Bug: dartbug.com/37311
Change-Id: If5bcff41a98c0053c581648a9ee22b3302ceea04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106740
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
dart-bytecode, arm64: +4.742% geomean
dart-bytecode-jit-unopt, arm64: +12.73% geomean
dart2js-compile, x64: +3.635% geomean
In the polymorphic and unlinked cases, call to a stub the does a linear scan against an ICData.
In the monomorphic case, call to a prologue of the expected target function that checks the expected receiver class. There is additional indirection in the JIT version compared to the AOT version to also tick a usage counter so the inliner can make good decisions.
In the megamorphic case, call to a stub that does a hash table lookup against a MegamorphicCache.
Megamorphic call sites face a loss of precision in usage counts. The call site count is not recorded and the usage counter of the target function is used as an approximation.
Monomorphic and megamorphic calls sites are reset to the polymorphic/unlinked state on hot reload.
Monomorphic and megamorphic calls sites do not check the stepping state, so they are reset to the polymorphic/unlinked state when stepping begins and disabled.
Back-edges now increment the usage counter in addition to checking it. This ensures function with loops containing monomorphic calls will eventually cross the optimization threshold.
Fixed backwards use of kMonomorphicEntryOffset and kPolymorphicEntryOffset.
Fixed C stack overflow when bouncing between the KBC interpreter and a simulator.
Bug: https://github.com/dart-lang/sdk/issues/26780
Bug: https://github.com/dart-lang/sdk/issues/36409
Bug: https://github.com/dart-lang/sdk/issues/36731
Change-Id: I78a49cccd962703a459288e71ce246ed845df474
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102820
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Rationale:
Previous method cached graph information (instruction and call site
counts) on a per-function level, not accounting for potential
specializations. The improved method runs an extra constant folding
pass, and only caches per-function information for non-specialized
cases. As a result, we inling much better, see for example, the
added test as illustration.
Since we no longer cache for constants, compile-time may be increased
a bit due to the extra scan. In the long run we should consider
for common constant "situations" as the call site.
https://github.com/dart-lang/sdk/issues/36880
Change-Id: I19f007c7f1860ad0ea88fafb38695dc154189ad5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105460
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This way, the new type information can be used immediately by
this and following passes instead of only passes after the next
type propagation phase.
Change-Id: Id27c3789c7c32f5775da5ef933bc56cb58c2a203
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101826
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In cases where the same target function is used for multiple
CID ranges, we only perform the inlining once. However, if the
CID range used for the initial inlining is a single CID, we will
set the type of the redefinition to that CID.
Detect this case and clear the concrete type associated with
the redefinition if it was given one.
Change-Id: I9f9bdd7c21e0dc1ac537f8facece0010630bd9aa
Cq-Include-Trybots: luci.dart.try:vm-kernel-win-debug-x64-try,vm-kernel-win-release-ia32-try,vm-kernel-win-product-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105221
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In cases where the same target function is used for multiple
CID ranges, we only perform the inlining once. However, if the
CID range used for the initial inlining is a single CID, we will
set the type of the redefinition to that CID.
Detect this case and clear the concrete type associated with
the redefinition if it was given one.
Change-Id: I3c27c46c71e10e71624ce3b969cb741eb9b2915f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104781
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>