In some cases, bailouts in the bg compiler, e.g. caused by class
finalization, mark functions as unoptimizable, which can significantly
slow down an application.
Instead of doing this, we mark these functions as non-optimizable on the
BG compiler and trigger re-compilations on the main thread.
Change-Id: Ifbb6aa7972818be8fa1313427e38d8b5576053e3
Reviewed-on: https://dart-review.googlesource.com/54886
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Metadata is no longer written ahead of all nodes. Instead, metadata for
each node is written in the same context as the node itself (into a separate
buffer). This allows metadata to contain (serialize) arbitrary nodes
(for example, arbitrary DartTypes) and use serialization context of parent
nodes (such as declared type parameters).
However, with this change metadata looses the ability to reference
arbitrary AST nodes. This ability was overly restricted and had no
practical uses. (It was not possible to reference nodes which are not
reachable from root Component. As a consequence, it was not possible to
write references to arbitrary DartTypes.)
This change aligns the serialization capabilities of metadata with
how kernel AST nodes are serialized.
Change-Id: I027299a33b599b62572eccd4aa7083ad1dd2b3b3
Reviewed-on: https://dart-review.googlesource.com/54481
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This is complicated by the fact that the normal factory method for creating
Invocation objects references the arguments descriptor to determine how many
type arguments are passed. This doesn't work for partially instantiated
closures, because the arguments descriptor will say "0" type arguments even when
there may be delayed type arguments attached to the closure from partial
instantiation. The arguments descriptor can't be modified, so we have a new
factory method which takes the number of delayed type arguments directly.
Change-Id: Ic9a35a482b3b7ef80564e674cc6207873e255111
Reviewed-on: https://dart-review.googlesource.com/54245
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
If call can have type arguments we can't use call->ArgumentAt(0) to
access receiver, instead we need to use call->ArgumentAt(call->FirstArgIndex()).
This lead to a bug in polymorphic inlining of functions with type
arguments - instead of loading class id from the receiver we would be
loading it from the first argument which contains type arguments.
This CL also cleans up other parts of the compiler that used ArgumentAt(0)
when they needed receiver.
Fixes https://github.com/dart-lang/protobuf/issues/95
Change-Id: I5504f7aff714894ff9fe580710c376f1d1933bfa
Reviewed-on: https://dart-review.googlesource.com/54411
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
This is the second try. First commit failed because another reading of
the binary was added after the change was originally made and before
actually landing it (and wasn't noticed when rebasing).
This reverts commit b298fc6d8f.
See 6e2536f585 for more information.
Change-Id: Ia0e7f8921de2cec8088654fa24950df13d846237
Reviewed-on: https://dart-review.googlesource.com/53560
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This reverts commit cf78da8a48.
Reason for revert: introduces significant performance regression (~30%) on analyzer benchmarks (warm-analysis) without clearly visible hot-spot.
Original change's description:
> [VM] Reduce Smi size to 32 bit on 64 bit platforms
>
> This reduces small tagged integers on 64 bit platforms from 63 bits to
> 31 bits plus one tag bit.
> This is a step on the way to compile-time-optional compressed pointers
> on 64 bit platforms. See more about this at go/dartvmlearnings
> This causes a slowdown for some uses of integers that don't fit in 31
> signed bits, but because both x64 and ARM64 have unboxed 64 bit
> integers now the performance hit should not be too bad.
>
> This is a reapplication of
> https://dart-review.googlesource.com/c/sdk/+/46244
> It was reverted due to a compilation error on 32 bit
> ARM with DBC.
>
> R=vegorov@google.com
>
> Change-Id: I943de1768519457f0e5a61ef0b4ef204b6a53281
> Reviewed-on: https://dart-review.googlesource.com/51321
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,erikcorry@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I8c5b909ec38663b5f5b05f69ef488c97341f8f3d
Reviewed-on: https://dart-review.googlesource.com/54000
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
This code is unused and has been bit-rotting for some time, so we'll
remove support for the kVector{Create,Copy,Get,Set}/kClosureCreation
kernel expressions.
Change-Id: Ie83d35b6d2cd533f3c08084631c5faf0c14ff122
Reviewed-on: https://dart-review.googlesource.com/53940
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Previously the graph was constructed in such a way that
:function_type_arguments_var was only initialized when we call the
function with yield points for the first time. Which meant that on
resumption we would the type arguments.
Alternative to this fix would be to capture :function_type_arguments_var
but that does not make sense: yield points only occur inside
non-generic functions at the moment, which means that :function_type_arguments_var
is cheaper then capturing it as it is just a load of a field
from the closure object.
Fixes https://github.com/dart-lang/sdk/issues/33025
Bug: 33025
Change-Id: I0543b64202511a6c48744d462e384cf8a79e903e
Reviewed-on: https://dart-review.googlesource.com/53664
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
call Internal_prependTypeArguments to protect against vector reuse optimization.
This is indirectly related to issue #33040.
Change-Id: Ic03805135b1c68b59234336e145f5578cf178c74
Reviewed-on: https://dart-review.googlesource.com/53692
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
This reverts commit 7d5025e814.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Fix incorrect handling of NSM forwarders and pull all logic into CFE.
>
> The original implementation was designed around a shared misunderstanding
> of optional parameter handling in the spec. (which was also ambiguous about type parameters).
>
> The correct behavior for optional/type parameters is to fill them in with their default values/bounds.
> This behavior can be implemented without any backend support, as is done in this CL.
>
> Change-Id: Ib81f17ead2d2920e755703e244db5afc328d0315
> Reviewed-on: https://dart-review.googlesource.com/52802
> Commit-Queue: Samir Jindel <sjindel@google.com>
> Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
TBR=dmitryas@google.com,sjindel@google.com
Change-Id: Ice6cd36cc62772e013bded83e0f589fe4b5e9d53
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/53400
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
The original implementation was designed around a shared misunderstanding
of optional parameter handling in the spec. (which was also ambiguous about type parameters).
The correct behavior for optional/type parameters is to fill them in with their default values/bounds.
This behavior can be implemented without any backend support, as is done in this CL.
Change-Id: Ib81f17ead2d2920e755703e244db5afc328d0315
Reviewed-on: https://dart-review.googlesource.com/52802
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Previously doubles was saved as strings in the string table,
with a DoubleLiteral holding a StringReference.
This can cause overhead in both computation time
(converting the double to and from string) as well as size
(e.g. a single usage of the previously unused double 1000000.42
would use (at least)
* 10 bytes for the characters
* 1 byte for the size
* 1 byte for the reference to the string
whereas saving it as a double would simply save the 8 bytes.
On the other hand the string table doesn't contain duplicates so
many usages of the same double will use more space.
The SDK dill file size decreases slightly (< 1 KB).
On a Dart file with 1M different doubles (0.42, 1.42, ..., 999999.42)
added to a list:
Before:
compile and write via fasta (non-strong-mode): 0:12.18
Reading (via dart, eager): 2500-2600 ms
Writing (to null sink) (after reading): 1600-1800 ms
Output dill file (via fasta compile): ~62 MB
After:
compile and write via fasta (non-strong-mode): 0:11.76
Reading (via dart, eager): 2050-2350 ms
Writing (to null sink) (after reading): 400-550 ms
Output dill file (via fasta compile): ~54 MB
Running the dill file is ~the same time, but "Maximum resident set size
(kbytes)" (from /usr/bin/time -v) decreases with ~4%.
On the other side, if it's 1M of the same doubles (0.42), while
compiling is ~the same speed, the output dill goes from 43MB to 50MB.
Surprisingly the "Maximum resident set size (kbytes)" still decreases
though (~3%).
Running flutter test in flutter/packages/flutter:
Before:
```
02:33 +2425 ~18: All tests passed!
02:28 +2425 ~18: All tests passed!
02:28 +2425 ~18: All tests passed!
```
After:
```
02:12 +2425 ~18: All tests passed!
02:11 +2425 ~18: All tests passed!
02:12 +2425 ~18: All tests passed!
```
So that's -12.0267% +/- 3.15253%
File size of a dill file of an arbitrary test using flutter is reduced by ~44 KB (~0.3%).
Change-Id: I64151376cde1dae6f0d02b3d96991bc432a994ae
Reviewed-on: https://dart-review.googlesource.com/41660
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL fixes error message in NoSuchMethodError thrown by null checks
and line numbers in corresponding stack traces (in AOT).
Name of the called function is placed into object pool, and metadata
for null check site is generated in CodeSourceMap.
Size of flutter gallery in release mode:
Before After
RW 2165286 2201642 (+1.68%)
RO 2122192 2168224 (+2.17%)
RX 6871072 6871072 (+0.00%)
Total 11163079 11245467 (+0.74%)
Closes https://github.com/dart-lang/sdk/issues/32863
Change-Id: I5ad1190f2ec9452a669863f7dd114ea5f9092d52
Reviewed-on: https://dart-review.googlesource.com/52703
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reduces small tagged integers on 64 bit platforms from 63 bits to
31 bits plus one tag bit.
This is a step on the way to compile-time-optional compressed pointers
on 64 bit platforms. See more about this at go/dartvmlearnings
This causes a slowdown for some uses of integers that don't fit in 31
signed bits, but because both x64 and ARM64 have unboxed 64 bit
integers now the performance hit should not be too bad.
This is a reapplication of
https://dart-review.googlesource.com/c/sdk/+/46244
It was reverted due to a compilation error on 32 bit
ARM with DBC.
R=vegorov@google.com
Change-Id: I943de1768519457f0e5a61ef0b4ef204b6a53281
Reviewed-on: https://dart-review.googlesource.com/51321
Reviewed-by: Vyacheslav Egorov <vegorov@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;
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>
Our generated code does not keep the context in a special register
anymore (for quite some time now). The context is just another definition
in the IR language and gets assigned register locations by the linearscan
register allocator.
Furthermore we no longer use an empty context for closures which have no
captured states, instead the context of those closures is just `null`.
This CL therefore removes Object::empty_context() and the CTX constant.
Change-Id: Iea171e0d0fd56c48f1c456e08e060a12267e39cc
Reviewed-on: https://dart-review.googlesource.com/51129
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@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>
This includes Fasta, tools and observatory, so the checked-in SDK must
have the lower-case constants.
Change-Id: I8380ad041ad058f7d02ae19caccfecd434d13d75
Reviewed-on: https://dart-review.googlesource.com/50201
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This "innocent" change was included in the type testing Part 1-4 and is
reverted here.
Apparently this causes uncorrect behavior in 1.0 precompiler
configuration.
Change-Id: I93c70400f621aca7185a17edea00907f4624d703
Reviewed-on: https://dart-review.googlesource.com/51301
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Relands 165c583d57
[VM] Introduction of type testing stubs - Part 1
This CL:
* Adds a field to [RawAbstractType] which will always hold a pointer
to the entrypoint of a type testing stub
* Makes this new field be initialized to a default stub whenever a
instances are created (e.g. via Type::New(), snapshot reader, ...)
* Makes the clustered snapshotter write a reference to the
corresponding [RawInstructions] object when writing the field and do
the reverse when reading it.
* Makes us call the type testing stub for performing assert-assignable
checks.
To reduce unnecessary loads on callsites, we store the entrypoint of the
type testing stubs directly in the type objects. This means that the
caller of type testing stubs can simply branch there without populating
a code object first. This also means that the type testing stubs
themselves have no access to a pool and we therefore also don't hold on
to the [Code] object, only the [Instruction] object is necessary.
The type testing stubs do not setup a frame themselves and also have no
safepoint. In the case when the type testing stubs could not determine
a positive answer they will tail-call a general-purpose stub.
The general-purpose stub sets up a stub frame, tries to consult a
[SubtypeTestCache] and bails out to runtime if this was unsuccessful.
This CL is just the the first, for ease of reviewing. The actual
type-specialized type testing stubs will be generated in later CLs.
Reviewed-on: https://dart-review.googlesource.com/44787
Relands f226c22424
[VM] Introduction of type testing stubs - Part 2
This CL starts building type testing stubs specialzed for [Type] objects
we test against.
More specifically, it adds support for:
* Handling obvious fast cases on the call sites (while still having a
call to stub for negative case)
* Handling type tests against type parameters, by loading the value
of the type parameter on the call sites and invoking it's type testing stub.
* Specialzed type testing stubs for instantiated types where we can
do [CidRange]-based subtype-checks.
==> e.g. String/List<dynamic>
* Specialzed type testing stubs for instantiated types where we can
do [CidRange]-based subclass-checks for the class and
[CidRange]-based subtype-checks for the type arguments.
==> e.g. Widget<State>, where we know [Widget] is only extended and not
implemented.
* Specialzed type testing stubs for certain non-instantiated types where we
can do [CidRange]-based subclass-checks for the class and
[CidRange]-based subtype-checks for the instantiated type arguments and
cid based comparisons for type parameters. (Note that this fast-case migth
result in some false-negatives!)
==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
extended and not implemented.
This optimizes cases where the caller uses `new HashMap<A, B>()` and only
uses `A` and `B` as key/values (and not subclasses of it). The false-negative
can occur when subtypes of A or B are used. In such cases we fall back to the
[SubtypeTestCache]-based imlementation.
Reviewed-on: https://dart-review.googlesource.com/44788
Relands 25f98bcc75
[VM] Introduction of type testing stubs - Part 3
The changes include:
* Make AssertAssignableInstr no longer have a call-summary, which
helps methods with several parameter checks by not having to
re-load/re-initialize type arguments registers
* Lazily create SubtypeTestCaches: We already go to runtime to warm up
the caches, so we now also create the caches on the first runtime
call and patch the pool entries.
* No longer load the destination name into a register: We only need
the name when we throw an exception, so it is not on the hot path.
Instead we let the runtime look at the call site, decoding a pool
index from the instructions stream. The destination name will be
available in the pool, at a consecutive index to the subtype cache.
* Remove the fall-through to N=1 case for probing subtypeing tests,
since those will always be handled by the optimized stubs.
* Do not generate optimized stubs for FutureOr<T> (so far it just
falled-through to TTS). We can make optimzed version of that later,
but it requires special subtyping rules.
* Local code quality improvement in the type-testing-stubs: Avoid
extra jump at last case of cid-class-range checks.
There are still a number of optimization opportunities we can do in
future changes.
Reviewed-on: https://dart-review.googlesource.com/46984
Relands 2c52480ec8
[VM] Introduction of type testing stubs - Part 4
In order to avoid generating type testing stubs for too many types in
the system - and thereby potentially cause an increase in code size -
this change introduces a smarter way to decide for which types we should
generate optimized type testing stubs.
The precompiler creates a [TypeUsageInfo] which we use to collect
information. More specifically:
a) We collect the destination types for all type checks we emit
(we do this inside AssertAssignableInstr::EmitNativeCode).
-> These are types we might want to generate optimized type testing
stubs for.
b) We collect type argument vectors used in instance creations (we do
this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
of used type argument vectors for each class.
After the precompiler has finished compiling normal code we scan the set
of destination types collected in a) for uninstantiated types (or more
specifically, type parameter types).
We then propagate the type argument vectors used on object allocation sites,
which were collected in b), in order to find out what kind of types are flowing
into those type parameters.
This allows us to extend the set of types which we test against, by
adding the types that flow into type parameters.
We use this final augmented set of destination types as a "filter" when
making the decision whether to generate an optimized type testing stub
for a given type.
Reviewed-on: https://dart-review.googlesource.com/48640
Issue https://github.com/dart-lang/sdk/issues/32603
Closes https://github.com/dart-lang/sdk/issues/32852
Change-Id: Ib79fbe7f043aa88f32bddad62d7656c638914b44
Reviewed-on: https://dart-review.googlesource.com/50944
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Martin Kustermann