This reverts commit af251ddfec.
Reason for revert: Crashes on Windows.
Original change's description:
> [vm] Prefer stack bounds from the system thread library for overflow checks.
>
> Before this change, we would assume all stacks have the size the VM specifies for threads it creates, but this won't be accurate for the initial thread or threads created by the embedder.
>
> Change-Id: I6605a88d6666a6f9d47fbe047d3fdd02aa22c80a
> Reviewed-on: https://dart-review.googlesource.com/10209
> Reviewed-by: Zach Anderson <zra@google.com>
TBR=rmacnak@google.com,zra@google.com
Change-Id: I96eaccdc8edf6e3d319827a63d168534bad0518e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/13106
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Before this change, we would assume all stacks have the size the VM specifies for threads it creates, but this won't be accurate for the initial thread or threads created by the embedder.
Change-Id: I6605a88d6666a6f9d47fbe047d3fdd02aa22c80a
Reviewed-on: https://dart-review.googlesource.com/10209
Reviewed-by: Zach Anderson <zra@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>
- Refactor the JumpToExceptionHandle code so that it is now built from
two pieces: JumpToFrame and RunExceptionHandler.
- Refactor the Simulator::Longjmp() code so that it is no longer
exception-specific. Instead it uses the RunExceptionHandler stub.
This makes it so that the JumpToFrame stub and Simulator::JumpToFrame
have the same semantics. This will make it easier to land the Rewind
changes I am working on.
There are some oddities for dbc.
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2503653002 .
i.e. #ifndef VM_WHATEVER -> #ifndef RUNTIME_VM_WHATEVER
This lets us remove a hack from the PRESUBMIT.py script that existed
for reasons that are no longer valid, and sets us up to add some
presubmit checks for the GN build.
R=asiva@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/2450713004 .
- 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 .
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 .
Martin Kustermann