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>
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 .
Ryan Macnak