CloneContext is implemented as a runtime call so it is considerably slower
than AllocateContext which leads to performance issues in loops that capture
iteration variables in for loops.
Lowering CloneContext into AllocateUninitializedContext and a sequence of
explicit load&store instructions both improves the performance by avoiding
the runtime call and also makes CloneContext semantics exposed to store-load
forwarding and allocation sinking.
PutIfAbsent benchmark from issue #31113 is improved by 5x, while
ForInGeneratedLoop benchmark is improved by 8x.
Bug: https://github.com/dart-lang/sdk/issues/31113
Change-Id: I03fdede75f1a85fda92487aa8f9307ce06f23903
Reviewed-on: https://dart-review.googlesource.com/16280
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Currently, the Kernel FE doesn't set up parent pointers correctly for
signature function types. This prevents type parameters on generic
function types from being finalized correctly. In addition, finalization
of generic interface types within a generic function type can crash if they
reference not-yet-finalized type parameters of the enclosing function type.
This review solves both issues. Several failing tests pass again, although
more thorough testing is blocked on Github issue #31213 (nested generic function
types crashing in Fasta).
Bug:
Change-Id: Ib5ee6b2566492e3fd6688fe5a6b6976692562ea1
Reviewed-on: https://dart-review.googlesource.com/16360
Reviewed-by: Régis Crelier <regis@google.com>
Currently, we have some tests that run with reified generic functions ON and
some with it OFF. However, this causes inconsistencies when running the Kernel
FE from snapshot in the VM, since the VM requires that the flag be consistent
with the snapshot. Our solution is to turn the reified generic functions flag
into a per-isolate flag, which is always disabled in the Kernel FE's isolate.
Bug:
Change-Id: Ia91e9f0ff5fc059edf4bdbd79ef14abb288b4a49
Reviewed-on: https://dart-review.googlesource.com/16020
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL improves performance of allocation statistic counters on ARM
by removing duplicated loads and increasing distance between dependent
loads. These statistic counters are part of allocator fast path in a
non-product mode.
This change improves performance of gestures/velocity_tracker_bench
Flutter micro-benchmark in 'flutter run --profile' mode:
Before: 3352 µs
After: 3156 µs (-5.8%)
(minimum of 5 runs)
Change-Id: Ic7998318d9ca3e7997379d0054faaf5b0b569bb6
Reviewed-on: https://dart-review.googlesource.com/15640
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This new object points to program wide data like string offsets,
string data etc. It also holds an array of pointers to all Script
objects corresponding scripts in the program's source table.
This new object type is required for two reasons:
1. The Script objects now have a number of fields which point to
program wide data. All Script objects point to the same data in the
VM heap. By introducing an indirection via this new object, we reduce
the number of pointers in Script objects.
2. Lazy loading of VM objects - Kernel nodes of
entities like fields and functions have a field which point to the
source file in which they are defined. This entry is an index into
the program wide source table and helps in associating
functions/fields with their actual source location. When lazy loading
functions and fields, the pre-loaded script objects in the
program's KernelProgramInfo help in associating the functions and
fields with the correct source script at load time.
Change-Id: Id863284ae7dd98b0832e5dfc115dabad1ed762d8
Reviewed-on: https://dart-review.googlesource.com/13920
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This flag indicates when a procedure's return type makes contravariant
use of a class type parameter. The front end will have to insert "as"
checks at any call sites that refer to such a procedure as their
interface target. Placing the flag on the procedure will allow the
front end to determine whether the check is needed once, at the same
time as it's determining the need for covariant parameter checks,
rather than when compiling individual call sites.
Once this lands I will follow up with CLs that cause the front end to
set the flag appropriately, and to generate the necessary "as" checks.
Change-Id: I989fc702bc233384eb5ea8cd630c8efd384ab248
Reviewed-on: https://dart-review.googlesource.com/14365
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Such a call site starts with a reference to a stub in the VM isolate, so the pointer was not recordered, but after it first runs it will be patched to a code object in the current isolate, which may move during compaction.
Bug: https://github.com/dart-lang/sdk/issues/30978
Change-Id: I3bf8fd1cf8884cbba9956254cad70f46e8b8cc00
Reviewed-on: https://dart-review.googlesource.com/12701
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously, a lot of recognized instance methods were inlined
only if they are called using InstanceCall instruction.
This CL enables inlining of such methods even if they are called
using StaticCall instruction. Such static calls may appear as the
result of devirtualization of instance calls.
Fixes slow-down of Flutter gestures/velocity_tracker benchmark when
devirtualization is enabled without --experimental-strong-mode.
(The slow-down was caused by inline heuristics rejecting to inline
several methods as their speculative bodies contain non-inlined
calls to recognized methods.)
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: Id0ec0669d0e3fe05aa708baec4a468892dbe7f8e
Reviewed-on: https://dart-review.googlesource.com/13200
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL optimizes Type.hashCode similarly to String.hashCode, by
introducing intrinsic version of hashCode calculation which uses
hashcode stored in Type instance.
This is important for Flutter's .of pattern, which heavily uses
Maps with Type keys.
Results on Flutter stocks/build_bench.dart microbenchmark:
Before: 4906 µs
After: 4751 µs
(minimum of 5 runs, using tip of Flutter and Flutter engine)
Issue: https://github.com/dart-lang/sdk/issues/31011
Issue: https://github.com/flutter/flutter/issues/11572
Change-Id: Ifbaf721050007db49bbd969dc669d070f4ce839e
Reviewed-on: https://dart-review.googlesource.com/12622
Reviewed-by: Zach Anderson <zra@google.com>
Devirtualization optimization now adds metadata to kernel AST instead
of transforming nodes to Direct* ones. The direct call metadata
provides information about checking receiver for null, while
Direct* kernel nodes do not support null checking.
VM's kernel binary loader is extended to extract arbitrary metadata
from kernel binaries and keep it for flow graph builder.
Kernel flow graph builder is extended to take direct call metadata
into account and generate CheckNull/StaticCall instructions
for devirtualized PropertyGet, PropertySet and MethodInvocation nodes.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I57f56fbf4a8981d33b1571c0d93105cf8ca71d76
Reviewed-on: https://dart-review.googlesource.com/12260
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Before this change, each function and field had its own kernel data blob
in the VM heap. With this change, the entire kernel data of a library is
stored as one single blob in the VM heap. Functions and fields store an
offset which points to the kernel data, specific to them, in that single
blob.
The pointer to the kernel data for a library is saved in two places:
1. With the library objects themselves.
2. With all the patch classes of the library.
3. With the patch classes created during hot reload.
Change-Id: Ie03e738c4d20f16056a5ef04341b75506fda9c60
Bug:
Reviewed-on: https://dart-review.googlesource.com/6601
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
When precompiling we might trigger optimizing compilation eagerly
so constant evaluation did not have a chance to run.
It is totally fine though because precompiler does not use
background thread.
Bug:
Change-Id: I6e889284d9ef9be8b09c6f4fe7695c82a78bcee4
Reviewed-on: https://dart-review.googlesource.com/12280
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This CL unifies 31 diverse Simd instructions into a single flexible SimdOp instruction.
These instructions were not different enough to warrant being implemented
as separate IL instructions. The separation did not bring any benefit but
instead we payed the price with considerable amounts of duplicated code
across the pipeline.
Main motivation for this refactoring is to reduce the surface of our IL.
Bug:
Change-Id: Ie8e39fecd2a51cb8edffdfe9c22e76835f912a9b
Reviewed-on: https://dart-review.googlesource.com/10120
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Rewrite most SIMD instructions on ARM using this new way.
Our current way for defining instruction backends -- a pair of two virtual
methods called MakeLocationSummary and EmitNativeCode, leads to unnecessary
duplicated and verbose code. Code generation happens in three steps:
1. For each instruction in the graph MakeLocationSummary is called to
constructing a location summary object encoding register allocation constraints;
2. When all register constraints are collected a register allocation is performed
and results are filled back into the location summaries;
3. For each instruction in the graph EmitNativeCode is called. It unpacks
location summary attached to the instruction into actual machine registers and
emits native code.
There is usually a lot of duplication between declaring register constraints in
MLS and unpacking them in ENC which this CL is trying to remove.
The new way is centered on the concept of an *emitter function* which encodes
in its signature register constraints for a particular instruction.
We use a combination of templates and macroses to enable writing
DEFINE_BACKEND(BinaryFloat32x4Op,
(QRegister result, QRegister left, QRegister right)) {
// ...
}
Instead of
LocationSummary* BinaryFloat32x4OpInstr::MakeLocationSummary(Zone* zone,
bool opt) const {
const intptr_t kNumInputs = 2;
const intptr_t kNumTemps = 0;
LocationSummary* summary = new (zone)
LocationSummary(zone, kNumInputs, kNumTemps, LocationSummary::kNoCall);
summary->set_in(0, Location::RequiresFpuRegister());
summary->set_in(1, Location::RequiresFpuRegister());
summary->set_out(0, Location::RequiresFpuRegister());
return summary;
}
void BinaryFloat32x4OpInstr::EmitNativeCode(FlowGraphCompiler* compiler) {
const QRegister left = locs()->in(0).fpu_reg();
const QRegister right = locs()->in(1).fpu_reg();
const QRegister result = locs()->out(0).fpu_reg();
// ...
}
This change also introduces a new, more handy way to work with S/D components of QRegisters, QRegister_ wrapper type.
Bug: https://github.com/dart-lang/sdk/issues/30949
Change-Id: I7bb0fc9672c89acc3d3d9b5e9859ae5a5471f420
Reviewed-on: https://dart-review.googlesource.com/11820
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit 04aa2b0186.
Reason for revert: Compilation is failing on some Windows builders. It may be the version of MSVC running on those machines that makes the difference. But I think we need to revert until we figure it out. The error is "runtime\vm\compiler\backend\locations_helpers_test.cc(111): error C2466: cannot allocate an array of constant size 0"
Original change's description:
> [VM] Introduce new way to define instruction backends.
>
> Rewrite most SIMD instructions on ARM using this new way.
>
> Our current way for defining instruction backends -- a pair of two virtual
> methods called MakeLocationSummary and EmitNativeCode, leads to unnecessary
> duplicated and verbose code. Code generation happens in three steps:
>
> 1. For each instruction in the graph MakeLocationSummary is called to
> constructing a location summary object encoding register allocation constraints;
> 2. When all register constraints are collected a register allocation is performed
> and results are filled back into the location summaries;
> 3. For each instruction in the graph EmitNativeCode is called. It unpacks
> location summary attached to the instruction into actual machine registers and
> emits native code.
>
> There is usually a lot of duplication between declaring register constraints in
> MLS and unpacking them in ENC which this CL is trying to remove.
>
> The new way is centered on the concept of an *emitter function* which encodes
> in its signature register constraints for a particular instruction.
>
> We use a combination of templates and macroses to enable writing
>
> DEFINE_BACKEND(BinaryFloat32x4Op,
> (QRegister result, QRegister left, QRegister right)) {
> // ...
> }
>
> Instead of
>
> LocationSummary* BinaryFloat32x4OpInstr::MakeLocationSummary(Zone* zone,
> bool opt) const {
> const intptr_t kNumInputs = 2;
> const intptr_t kNumTemps = 0;
> LocationSummary* summary = new (zone)
> LocationSummary(zone, kNumInputs, kNumTemps, LocationSummary::kNoCall);
> summary->set_in(0, Location::RequiresFpuRegister());
> summary->set_in(1, Location::RequiresFpuRegister());
> summary->set_out(0, Location::RequiresFpuRegister());
> return summary;
> }
>
> void BinaryFloat32x4OpInstr::EmitNativeCode(FlowGraphCompiler* compiler) {
> const QRegister left = locs()->in(0).fpu_reg();
> const QRegister right = locs()->in(1).fpu_reg();
> const QRegister result = locs()->out(0).fpu_reg();
> // ...
> }
>
> This change also introduces a new, more handy way to work with S/D components of QRegisters, QRegister_ wrapper type.
>
> Bug: https://github.com/dart-lang/sdk/issues/30949
> Change-Id: I7f2beb106d1458facf4a3d75cae123e1fc25d8b5
> Reviewed-on: https://dart-review.googlesource.com/11507
> Reviewed-by: Zach Anderson <zra@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,alexmarkov@google.com,zra@google.com
Change-Id: Icfaabe58351a61d4eb50c4f9ac3bbd9677339fe7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/30949
Reviewed-on: https://dart-review.googlesource.com/11780
Reviewed-by: William Hesse <whesse@google.com>
Rewrite most SIMD instructions on ARM using this new way.
Our current way for defining instruction backends -- a pair of two virtual
methods called MakeLocationSummary and EmitNativeCode, leads to unnecessary
duplicated and verbose code. Code generation happens in three steps:
1. For each instruction in the graph MakeLocationSummary is called to
constructing a location summary object encoding register allocation constraints;
2. When all register constraints are collected a register allocation is performed
and results are filled back into the location summaries;
3. For each instruction in the graph EmitNativeCode is called. It unpacks
location summary attached to the instruction into actual machine registers and
emits native code.
There is usually a lot of duplication between declaring register constraints in
MLS and unpacking them in ENC which this CL is trying to remove.
The new way is centered on the concept of an *emitter function* which encodes
in its signature register constraints for a particular instruction.
We use a combination of templates and macroses to enable writing
DEFINE_BACKEND(BinaryFloat32x4Op,
(QRegister result, QRegister left, QRegister right)) {
// ...
}
Instead of
LocationSummary* BinaryFloat32x4OpInstr::MakeLocationSummary(Zone* zone,
bool opt) const {
const intptr_t kNumInputs = 2;
const intptr_t kNumTemps = 0;
LocationSummary* summary = new (zone)
LocationSummary(zone, kNumInputs, kNumTemps, LocationSummary::kNoCall);
summary->set_in(0, Location::RequiresFpuRegister());
summary->set_in(1, Location::RequiresFpuRegister());
summary->set_out(0, Location::RequiresFpuRegister());
return summary;
}
void BinaryFloat32x4OpInstr::EmitNativeCode(FlowGraphCompiler* compiler) {
const QRegister left = locs()->in(0).fpu_reg();
const QRegister right = locs()->in(1).fpu_reg();
const QRegister result = locs()->out(0).fpu_reg();
// ...
}
This change also introduces a new, more handy way to work with S/D components of QRegisters, QRegister_ wrapper type.
Bug: https://github.com/dart-lang/sdk/issues/30949
Change-Id: I7f2beb106d1458facf4a3d75cae123e1fc25d8b5
Reviewed-on: https://dart-review.googlesource.com/11507
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
- We no longer erase type parameters of generic non-closures in the body of closures.
- We implement support for captured type parameters in the VM.
Bug:
Change-Id: I4f2f19301df1b44108ab2073332934d5d083e219
Reviewed-on: https://dart-review.googlesource.com/10942
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Previously we could hit an assert when for instance "42 ~/ 0"
was being optimized by the background compiler. The reason was
that we assert that we're on the "mutator thread" when allocating
memory (which is done as we're evaluating the code - and we're
trying to evaluate it again because evaluating it gives an error,
and errors aren't cached).
However, to create a test for this it would be better if we could
make it always crash, i.e. use something like
```
--optimization_counter_threshold=5 --no-background-compilation
```
to force an optimization, but still make it crash dispite the
optimization happening in mutator thread (because of
--no-background-compilation).
This CL propagates if we're optimizing to the kernel builder,
and in the constant builder further more asserts that we're not.
Additionally it introduces a test that shows the crash and fixes it.
Change-Id: Ic5412ec8b8a1dbc2ba323f0a02a51103a32fab5c
Reviewed-on: https://dart-review.googlesource.com/11380
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
There are three types of changes in this CL:
* If there is a repeated per-component sequence of instruction, it is
replaced with a loop (e.g. see Float32x4ConstructorInstr);
* When accessing components in the spilled SIMD values don't use
hardcoded constants but instead compute the offset from op_kind()
(e.g. kFloat32x4WithZ accesses component with index kFloat32x4WithZ - kFloat32x4WithX = 2).
This allows to share code.
* Use setcc and arithmetic to materialize result of the comparison instead of branches;
* Use the fact that true and false are consecutive values in the Thread structure to convert
0/1 to true/false (see Int32x4GetFlagInstr)
* Extract Int32x4 components without spilling the whole SIMD value to the
stack (see Int32x4GetFlagInstr).
This extracted from a larger refactoring CL: https://dart-review.googlesource.com/c/sdk/+/10120
Bug: https://github.com/dart-lang/sdk/issues/30949
Change-Id: Ic3757789a1ca621b267150133991fed5b85da633
Reviewed-on: https://dart-review.googlesource.com/11080
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
In kernel the loop level wasn't set correctly for for loops, resulting
in the loop variable not always being fresh.
Examples:
```
// Capture the loop variable, ensure we capture the right value.
for (int i = 0; i < 10; i++) { if (i == 7) f = () => "i = $i"; }
print(f());
// There is only one instance of k. The captured variable continues to change.
int k;
for (k = 0; k < 10; k++) { if (k == 7) f = () => "k = $k"; }
print(f());
```
resulted in
i = 10
k = 10
(i.e. it's wrong)
whereas
```
// Capture the loop variable, ensure we capture the right value.
for (int i = 0; i < 10; i++) { if (i == 7) { f = () => "i = $i"; } }
print(f());
{
// There is only one instance of k. The captured variable continues to change.
int k;
for (k = 0; k < 10; k++) { if (k == 7) { f = () => "k = $k"; } }
print(f());
}
```
resultet in
i = 7
k = 10
(i.e. it's correct).
Now both examples produce the correct result.
Change-Id: I1fb4c888c6a0eaa690f62226e093508992b33ed4
Reviewed-on: https://dart-review.googlesource.com/9961
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Previously we got the length of the class' type_parameters().
Now instead we use the class' NumTypeArguments().
Bug:
Change-Id: I3807443765e4926efc17eba54d3bf4f50e8e30c6
Reviewed-on: https://dart-review.googlesource.com/9482
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
In this CL most of the code generation logic of UnboxInstr is unified
among architectures and moved to a platform-independent part.
In addition:
* Asm comment corrected for check null slow path.
* Non-instantiated generic types are eagerly converted to dynamic in
type propagator.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: Idcb2c67938e63ac79cf78d125451bd485247daad
Reviewed-on: https://dart-review.googlesource.com/9741
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Ryan Macnak