Unoptimized code has a static call to optimized code.
Optimized code prologue goes to the OptimizeInvokedFunction runtime.
Callee schedule for background compilation and current code set the return entries return value.
Verify-on-transition triggers a safepoint, wherein the background compiler disables the old optimized code.
The OptimizedInvokedFunction stub calls through the disabled code.
FixCallersTarget see an unoptimized caller. BOOM
Similar problem without --verify-on-transition, except the safepoint comes from BackgroundCompiler::CompileOptimized.
Fixes#26927.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2418673002 .
Flutter layout benchmark 14k us -> 10k us. ~30%
improvement in checked mode. There still appear
to be a lot of checks that should be hitting the
cache, so there may be other fast-paths needed
as well.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2404163004 .
Added two new bytecodes: LoadFieldExt, StoreFieldExt that
store the field offset in the following nop-instruction that
is skipped. This allows offsets up to 16 bit.
BUG=
R=zra@google.com
Review URL: https://codereview.chromium.org/2399333003 .
- Fix setting exit frame info to indicate when we are executing Dart code.
- Copy local pc to memory on call and return to make it accessible to the profiler. Since the profiler cannot access the local pc, the profiler is not accurate at the instruction level.
- Teach the profiler's stack walker that the stack grows up for Dart frames on DBC.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2250823002 .
This CL enables unboxed doubles for simdbc64. Unboxed
doubles are stored in regular dbc registers, which are
really 64-bit stack slots. It also implements binary
and unary double operations and comparisons.
R=vegorov@google.com
Review URL: https://codereview.chromium.org/2120703002 .
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 .
There were differences between linux gcc, android gcc,
MacOS clang, and 32 vs. 64-bit w.r.t the __builtin
functions for detecting arithmetic overflow. I couldn't get
them all working at the same time. Instead, I removed them,
and changed to always use the inline assembly. This works
in all the configurations above.
This change also adds a simdbc64 target for building simdbc
for 64-bit, and sets up the android targets. simdbc targets
arm, and simdbc64 targets arm64. You can build them with:
$ ./tools/build.py -m release -a simdbc{64} --os=android runtime
R=iposva@google.com
Review URL: https://codereview.chromium.org/1904153003 .
Zachary Anderson