When the constant transformation is enabled on annotations, we need to fix handling
of @ExternalName annotations in the kernel_loader to ensure that we are setting
is_external = false on native methods.
The original revision is in patchset 1.
# Test Plan
The only regression was on benchmarks, Golem results are pending.
Change-Id: Ib80bb9f532299056e770a3b378cc5ad9ee451f57
Reviewed-on: https://dart-review.googlesource.com/56960
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit 3e50ea32b5.
Reason for revert: Severe performance regressions on many aot-v2 benchmarks.
Original change's description:
> [vm] Support definition of entry-points via @pragma('vm.extern') annotations.
>
> The `@pragma` annotations are evaluated by the constants transformation and
> visible to TFA and the precompiler, which match on the "options" field of the
> annotation to determine whether to mark the class/procedure as a root.
>
> This required enabling the transformation of annotation constants by default.
>
> # Test Plan
>
> The "vmservice_io.main" entry-point is removed from `main.cc` and annotated with
> `@pragma`. All precompiler tests will crash if "vmservice_io.main" is not
> available at runtime.
>
> Debug/release precompiler bots are visible in "cl-linux" button.
>
> Change-Id: I03c5d6ba7918672ed9905fcaee8dabe675a93a5d
> Reviewed-on: https://dart-review.googlesource.com/56660
> Commit-Queue: Samir Jindel <sjindel@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,alexmarkov@google.com,sjindel@google.com
Change-Id: I779c17d003659129a4b3fcf284423104948f60e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/56820
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
The `@pragma` annotations are evaluated by the constants transformation and
visible to TFA and the precompiler, which match on the "options" field of the
annotation to determine whether to mark the class/procedure as a root.
This required enabling the transformation of annotation constants by default.
# Test Plan
The "vmservice_io.main" entry-point is removed from `main.cc` and annotated with
`@pragma`. All precompiler tests will crash if "vmservice_io.main" is not
available at runtime.
Debug/release precompiler bots are visible in "cl-linux" button.
Change-Id: I03c5d6ba7918672ed9905fcaee8dabe675a93a5d
Reviewed-on: https://dart-review.googlesource.com/56660
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@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>
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>
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>
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>
We add two things:
* --print_instruction_stats makes compiler dump per IL instruction size
breakdown (how many bytes of code were produced from specific instruction
kinds). This was largely implemented by kustermann@ in
https://codereview.chromium.org/2584613002/ and this CL does only few changes
to the original implementation, namely more uniform handling of slow-path code
and puts statistics object into RawInstructions (which has free space due to
alignment) instead of RawCode.
* --print_instructions_sizes_to=symbols.json makes compiler dump per Instruction
object size breakdown into a JSON file. This JSON file can later be processed
with pkg/vm/tool/run_binary_size_analysis.dart script to produce interactive
binary size diagram similar to runtime/third_party/binary_size tool.
Change-Id: Ied4965b9a0a91b3025eefbe981ecd47cdcf782d6
Reviewed-on: https://dart-review.googlesource.com/50501
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@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
Change-Id: I6d33d4ca3d5187a1eb1664078c003061855f0160
Reviewed-on: https://dart-review.googlesource.com/50482
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@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
Change-Id: I44a1d5d4b27454ae026aef2a301aada3dd399ea0
Reviewed-on: https://dart-review.googlesource.com/49861
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
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.
Issue https://github.com/dart-lang/sdk/issues/32603
Measured impact on flutter HEAD-HEAD-HEAD with TTS Part 1 - 4 applied (2018-04-03):
* stock build benchmark: around 4% improvement
* gallery app.so size: -2.68% (13987348 -> 13612928)
* gallery memory: no sigificant changes:
- SubtypeTestCache: - 10kb
- ObjectPool: + 6 kb
- Type: no change (probably due to wasted alignment slot before)
- TypeParameter: + 4 kb (can get rid of the field here later)
* gallery AOT compile-time: measured +1.3%, inside flakiness range
Change-Id: I12a398d18f970ba2db741913bb47b0f36ae38d58
Reviewed-on: https://dart-review.googlesource.com/48640
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
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.
Issue https://github.com/dart-lang/sdk/issues/31798
Change-Id: Ic1853977bf55d815755b0d652ec8e20e51efb4cf
Reviewed-on: https://dart-review.googlesource.com/44788
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Régis Crelier <regis@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>
This CL adds auto-generation of entry points JSON file for standalone VM
during build (in runtime_kernel target, as it is only used for
kernel-based transformation).
pkg/vm/tool/precompiler2 script is changed to automatically pass
auto-generated entry points to gen_kernel.
New option --entry-points is added to pkg/vm/bin/gen_kernel.dart in order to
specify custom entry points files.
Checked-in entry_points.json is still used for testing and in gen_kernel
if --entry-points is not specified.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I39c4461e48763f40d7565656dc33e23fc5d9c2cb
Reviewed-on: https://dart-review.googlesource.com/42521
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
This the second part of fixing #32077 - dealing with mints.
Example:
The runtime of a program adding 100,000 different mints to
a list and prints the last one:
Before: ~12.5 seconds
Now: ~1.2 seconds.
Change-Id: Iad6da1749886bab4e4d3941748cdbab51661c2c3
Reviewed-on: https://dart-review.googlesource.com/41161
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This the first part of fixing #32077 - dealing with doubles.
Example:
The runtime of a program adding 100,000 different doubles to
a list and prints the last one:
Before: ~12 seconds
Now: ~1.3 seconds.
Change-Id: I7f64b8763fdd37dae5d32d3275f8b9c991d4e43a
Reviewed-on: https://dart-review.googlesource.com/40300
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When the type to test against is instantiated and has no type arguments
there is a high probability that we receive instances of that class or
subclasses at runtime.
This CL therefore extends the fast-path of AssertAssignable/InstanceOf
by checking whether the instance class id is within the cid ranges that
directly/indirectly implement/extend the type to test against.
Currently we have an almost depth-first preorder numbering of class ids
in AOT, but there are exceptions. So each class can have a number of
cid-ranges as subclasses / classes which implement it's interface.
This seems to improve performance of dart-aot-v2
* flutter stock build by 15+%
* DeltaBlueClosures by 10+%
and reduces code size on
* flutter gallery by -3%
Issue https://github.com/dart-lang/sdk/issues/31798
Change-Id: I07dd91589cc3fcd8c5952bdba339e2e2a459e08e
Reviewed-on: https://dart-review.googlesource.com/35620
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL extends support of mixed operations in strong-mode AOT
from double/smi to double/int (if underlying code generator supports
conversions from int64 to double).
* MintToDouble instruction is renamed to Int64ToDouble.
* Code generation of Int64ToDouble is implemented on x64.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I3142302e80c2785be71d7a8baff42d40f0b5b1b8
Reviewed-on: https://dart-review.googlesource.com/35382
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When AOT call specializer computes single target for a method
invocation it needs to ignore artificial methods like field
dispatchers and method extractors that are lazily injected
by the precompiler as compilation of the whole application
progresses.
Lazy injections means that we don't have complete knowledge
when we compile a single method.
Bug:
Change-Id: I249ca397bb3da89f512a1ace49b198a0ffc9bf97
Reviewed-on: https://dart-review.googlesource.com/30520
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
If we know that receiver is a subclass of a certain type and that this
type has accessor get:m then call o.m(...) is guaranteed to be an
invocation through a getter. Such invocations are executed most
efficiently when expanded into o.get:m().call(...).
Source based pipeline handles this case (at least for invocations on
`this`) directly in the parser, but Kernel based graph builder does not
have this sort of special case.
Instead of teaching Kernel flow graph builder to specially handle
invocations on `this` we teach AOT call specializer to specially handle
all invocations where receiver is known to be a subclass of certain
class. Such optimization is more generic and handles things that
previously were not handled by the optimization.
AOT compiler also has heuristics for injecting field dispatchers into
classes but these heuristics only handle fields of function type and
don't work for fields like `Function f` or `var f`.
Improves ParserCombinators benchmark by 4x.
This relands eea2c168f9 with a fix.
Change-Id: I13a41544c737b980efd431e31e4d15ad31da853e
Reviewed-on: https://dart-review.googlesource.com/30455
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Strong mode types are queried from:
* Return types of interface targets of instance calls.
* Return types of static calls.
* Types of instance and static fields.
* Types of local variables (for initial types of phis).
The strong mode types are used to specialize int and double operations
and optimize 'is' checks.
https://github.com/dart-lang/sdk/issues/30480
Change-Id: I2302509f396eacfcab8ed41e3f50e8c74dd662fd
Reviewed-on: https://dart-review.googlesource.com/30386
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit eea2c168f9.
Reason for revert: standalone_2/io/test_runner_test times out
python tools/test.py -m release -c precompiler -r dart_precompiled -a simarm64 --use-blobs standalone_2/io/test_runner_test
Original change's description:
> [vm] Detect and expand calls through getters in AOT call specializer.
>
> If we know that receiver is a subclass of a certain type and that this
> type has accessor get:m then call o.m(...) is guaranteed to be an
> invocation through a getter. Such invocations are executed most
> efficiently when expanded into o.get:m().call(...).
>
> Source based pipeline handles this case (at least for invocations on
> `this`) directly in the parser, but Kernel based graph builder does not
> have this sort of special case.
>
> Instead of teaching Kernel flow graph builder to specially handle
> invocations on `this` we teach AOT call specializer to specially handle
> all invocations where receiver is known to be a subclass of certain
> class. Such optimization is more generic and handles things that
> previously were not handled by the optimization.
>
> AOT compiler also has heuristics for injecting field dispatchers into
> classes but these heuristics only handle fields of function type and
> don't work for fields like `Function f` or `var f`.
>
> Improves ParserCombinators benchmark by 4x.
>
> Bug:
> Change-Id: I365d4fb2140577d02aefbf16fcf6be1bd12413a6
> Reviewed-on: https://dart-review.googlesource.com/29840
> Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
TBR=vegorov@google.com,kustermann@google.com,alexmarkov@google.com
Change-Id: I2b891b1674dd07fa43d6414428438c41e3332391
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/30400
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
If we know that receiver is a subclass of a certain type and that this
type has accessor get:m then call o.m(...) is guaranteed to be an
invocation through a getter. Such invocations are executed most
efficiently when expanded into o.get:m().call(...).
Source based pipeline handles this case (at least for invocations on
`this`) directly in the parser, but Kernel based graph builder does not
have this sort of special case.
Instead of teaching Kernel flow graph builder to specially handle
invocations on `this` we teach AOT call specializer to specially handle
all invocations where receiver is known to be a subclass of certain
class. Such optimization is more generic and handles things that
previously were not handled by the optimization.
AOT compiler also has heuristics for injecting field dispatchers into
classes but these heuristics only handle fields of function type and
don't work for fields like `Function f` or `var f`.
Improves ParserCombinators benchmark by 4x.
Bug:
Change-Id: I365d4fb2140577d02aefbf16fcf6be1bd12413a6
Reviewed-on: https://dart-review.googlesource.com/29840
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The only fix needed for relanding is adding _ensureScheduleImmediate
to the list of vm entrypoints in //runtime/vm/compiler/aot/precompiler.cc
Original commit message:
Adds a top-level call waitForEventSync to dart:io that blocks the
thread an Isolate is running on until messages are available.
Before the thread blocks, the microtask queue is drained.
Before waitForEventSync returns, all messages are handled.
Lifting this up from a comment:
This is apropos of the request that nweiz@ sent to the mailing list a
couple weeks back. I'm not sure we should land this. We certainly
shouldn't land it without some annotations that will make the analyzer
complain a lot in most configurations, but I don't know what those
annotations are.
fixes#31102
Change-Id: Id96de46cc5f10e1847045cfafb7cfed6a38bce16
Reviewed-on: https://dart-review.googlesource.com/28920
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
* CompileStaticInitializer() should check result of Compile()
and should not leave sticky error. If left, this sticky error
could be picked up by compilation of some unrelated static
initializer. Also, assertions are added to make sure that code
which explicitly or implicitly relies on sticky errors is not
getting an error on entry.
* CompileStaticInitializerIgnoreErrors() clears sticky errors to
ignore them.
* Added inline bailout reason for cyclic static fields.
This guards against inlining of code which uses a field into static
initializer. This code might not be called so it should not trigger
compilation error eagerly.
Change-Id: I52da6f4cd05556125fd1a628b665dcc11621a4f7
Reviewed-on: https://dart-review.googlesource.com/28523
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This CL extends RelationalOpInstr, BinaryInt64OpInstr, BinaryDoubleOpInstr,
UnaryDoubleOpInstr and unboxing instructions (UnboxInstr, UnboxIntegerInstr,
UnboxInteger32Instr, UnboxUint32Instr, UnboxInt32Instr and UnboxInt64Instr)
with non-speculative mode, when types of the inputs are not checked.
The non-speculative mode is used when generating double and int64 operations
in AOT using strong mode types.
Also, this CL disables couple of cases in --experimental-strong-mode which
do not work yet. This is a preparation for turning --experimental-strong-mode
on by default.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: Ic1f89e7f6fd9592d5a92671963283c7181ce1504
Reviewed-on: https://dart-review.googlesource.com/27841
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The info_array is needed to visit an ObjectPool's pointers, requiring the compactor to move the info_array's body before forwarding the ObjectPool's pointers. Moving the info_array inline remove this constraint on the compactor.
Also saves 3 words per ObjectPool modulo allocation size rounding.
Bug: https://github.com/dart-lang/sdk/issues/30978
Change-Id: I94de0e4b7356d46fb145efee7ab14abd7473eb4c
Reviewed-on: https://dart-review.googlesource.com/27480
Reviewed-by: Erik Corry <erikcorry@google.com>
Alexander Markov