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>
This reverts commit fde6a5917e.
Reason for revert: This commit looks to be causing new test failures on dart2js. While there are some odd results on some builders that look like infra failures, some builders (for example, dart2js-minified-strong-linux-x64-d8) show the new failing tests clearly.
Original change's description:
> [vm, compiler] Unoptimized megamorphic calls.
>
> When an instance call in unoptimized code creates more than FLAG_max_polymorphic_checks cases, switch the call to use a MegamorphicCache instead of ICData. The prevents unbounded collection of type feedback, and gives improvements on microbenchmarks in the 3-8% range for unoptimized code.
>
> It also leads to a loss of target frequency information for the optimizer, leading to different ordering for range checks in polymorphic inlining. This leads to changes on megamorphic microbenchmarks from -31% to +60%, weighted toward the negative end.
>
> In practice the frequency information seems unimportant, as dart2js has 4.01% geomean improvement.
>
> This is a step toward direct monomorphic calls in unoptimized code, which will also make use of the patching and type feedback extraction added here.
>
> 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: I29f53f23b6794c5f5f0db8b8184788cee16fd9c5
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99270
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,ajcbik@google.com
Change-Id: Icad46b93cdf8541a00563f49da6b4ac0a4df1ba1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/26780, https://github.com/dart-lang/sdk/issues/36409, https://github.com/dart-lang/sdk/issues/36731
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103440
Reviewed-by: Teagan Strickland <sstrickl@google.com>
Commit-Queue: Teagan Strickland <sstrickl@google.com>
When an instance call in unoptimized code creates more than FLAG_max_polymorphic_checks cases, switch the call to use a MegamorphicCache instead of ICData. The prevents unbounded collection of type feedback, and gives improvements on microbenchmarks in the 3-8% range for unoptimized code.
It also leads to a loss of target frequency information for the optimizer, leading to different ordering for range checks in polymorphic inlining. This leads to changes on megamorphic microbenchmarks from -31% to +60%, weighted toward the negative end.
In practice the frequency information seems unimportant, as dart2js has 4.01% geomean improvement.
This is a step toward direct monomorphic calls in unoptimized code, which will also make use of the patching and type feedback extraction added here.
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: I29f53f23b6794c5f5f0db8b8184788cee16fd9c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99270
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This is the next step towards preventing compiler from directly peeking
into runtime and instead interact with runtime through a well defined
surface. The goal of the refactoring to locate all places where compiler
accesses some runtime information and partion those accesses into two
categories:
- creating objects in the host runtime (e.g. allocating strings, numbers, etc)
during compilation;
- accessing properties of the target runtime (e.g. offsets of fields) to
embed those into the generated code;
This change introduces dart::compiler and dart::compiler::target namespaces.
All code in the compiler will gradually be moved into dart::compiler namespace.
One of the motivations for this change is to be able to prevent access to
globally defined host constants like kWordSize by shadowing them in the
dart::compiler namespace.
The nested namespace dart::compiler::target hosts all information about
target runtime that compiler could access, e.g. compiler::target::kWordSize
defines word size of the target which will eventually be made different
from the host kWordSize (defined by dart::kWordSize).
The API for compiler to runtime interaction is placed into compiler_api.h.
Note that we still permit runtime to access compiler internals directly -
this is not going to be decoupled as part of this work.
Issue https://github.com/dart-lang/sdk/issues/31709
Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20
Reviewed-on: https://dart-review.googlesource.com/c/90242
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@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>
Because DBC still uses code patching to implement breakpoints, running a program from DBC AppJIT may trigger a crash attempting to set a breakpoint.
Change-Id: I5d761aacec6629be946d7d2510ec3f1e3f03f4a4
Reviewed-on: https://dart-review.googlesource.com/42584
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Ryan Macnak <rmacnak@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>
New folder structure (nested under vm/):
- compiler/
- jit/ - JIT specific code
- aot/ - AOT specific code
- backend/ - all middle-end and back-end code (IL, flow graph)
- assembler/ - assemblers and disassemblers
- frontend/ - front ends (AST -> IL, Kernel -> IL)
compiler/README.md would be the documentation root for the compiler
pipeline
Bug: https://github.com/dart-lang/sdk/issues/30575
Change-Id: I2dfd9688793bff737f7632ddc77fca766875ce36
Reviewed-on: https://dart-review.googlesource.com/2940
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
When throwing to a frame scheduled for lazy deopt, update the continuation pc for that frame to be the catch handler.
Weaken new assert that the deopt pc belongs to the frame's code as the deopt pc for the last eager deopt in a function lies outside the code, after the call to the deopt stub.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2392613002 .
The call sequence is very similar to a classic IC call, except the guarded class and the target are loaded indirectly from the constant pool instead of as immediates. In the monomorphic case, we call directly to the expected target with a class check in the callee. In the unlinked, polymorphic and megamorphic cases, we call a stub; these case are now call-through instead of call-and-return.
Every code, except stubs involved in switchable calls, includes the class check sequence at the beginning. So we now distinguish between a checked and an unchecked entry point. Generated code except the switchable call continues to use the unchecked entry point.
PC offsets are calculated relative to the beginning of the instruction stream, rather than either entry point.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2226893002 .
Most of the infrastructure is fixed to work with DBC stack layout:
- register allocator allocates DBC registers with the limitation that we allocate only 20 registers and bail out if anything needs spilling (there is no use implementing spilling on DBC because registers are memory locations themselves). We should be able to bump number of CPU registers on DBC up to 256 but this requires major surgery in some parts - so I postponed this;
- lazy deoptimization is implemented, eager deoptimization is not - because we don't emit any code that actually requires it. it's a minor change to support it once we have a target;
- stack scanning respects stack maps built by registers allocator;
We bailout from all unsupported instructions.
R=zra@google.com
Review URL: https://codereview.chromium.org/1992963002 .
