There is no need to adjust instruction address by Page::AliasOffset()
when copying them to the image, as instructions are still readable
even if dual-mapped. The adjustment can be harmfull if Code is not
properly finalized and instructions in the Code are not replaced
with executable version.
TEST=ci
Fixes https://github.com/dart-lang/sdk/issues/51525
Cq-Include-Trybots: luci.dart.try:vm-linux-debug-x64c-try,vm-win-debug-x64c-try
Change-Id: I4af0ded149f27f6a68d2962805748d1eef6625e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286022
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
- Prep work for non-moving promotion.
- The generations still have different alignment offsets.
- Old-space pages now participate in the page cache.
- Fix boolean/null bit tricks to assert the right requirements on the alignment of a page's first object.
TEST=ci
Change-Id: I4369d8c6af73228e162c226d411914868bafed33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/260401
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Implements a backend targeting RV32GC and RV64GC, based on Linux standardizing around GC. The assembler is written to make it easy to disable usage of C, but because the sizes of some instruction sequences are compile-time constants, an additional build configuration would need to be defined to make use of it.
The assembler and disassembler cover every RV32/64GC instruction. The simulator covers all instructions except accessing CSRs and the floating point state accessible through such, include accrued exceptions and dynamic rounding mode.
Quirks:
- RISC-V is a compare-and-branch architecture, but some existing "architecture-independent" parts of the Dart compiler assume a condition code architecture. To avoid rewriting these parts, we use a peephole in the assembler to map to compare-and-branch. See Assembler::BranchIf. Luckily nothing depended on taking multiple branches on the same condition code set.
- There are no hardware overflow checks, so we must use Hacker's Delight style software checks. Often these are very cheap: if the sign of one operand is known, a single branch is needed.
- The ranges of RISC-V branches and jumps are such that we use 3 levels of generation for forward branches, instead of the 2 levels of near and far branches used on ARM[64]. Nearly all code is handled by the first two levels with 20-bits of range, with enormous regex matchers triggering the third level that uses aupic+jalr to get 32-bits of range.
- For PC-relative calls in AOT, we always generate auipc+jalr pairs with 32-bits of range, so we never generate trampolines.
- Only a subset of registers are available in some compressed instructions, so we assign the most popular uses to these registers. In particular, THR, TMP[2], CODE and PP. This has the effect of assigning CODE and PP to volatile registers in the C calling convention, whereas they are assigned preserved registers on the other architectures. As on ARM64, PP is untagged; this is so short indices can be accessed with a compressed instruction.
- There are no push or pop instructions, so combining pushes and pops is preferred so we can update SP once.
- The C calling convention has a strongly aligned stack, but unlike on ARM64 we don't need to use an alternate stack pointer. The author ensured language was added to the RISC-V psABI making the OS responsible for realigning the stack pointer for signal handlers, allowing Dart to leave the stack pointer misaligned from the C calling convention's point of view until a foreign call.
- We don't bother with the link register tracking done on ARM[64]. Instead we make use of an alternate link register to avoid inline spilling in the write barrier.
Unimplemented:
- non-trivial FFI cases
- Compressed pointers - No intention to implement.
- Unboxed SIMD - We might make use of the V extension registers when the V extension is ratified.
- BigInt intrinsics
TEST=existing tests for IL level, new tests for assembler/disassembler/simulator
Bug: https://github.com/dart-lang/sdk/issues/38587
Bug: https://github.com/dart-lang/sdk/issues/48164
Change-Id: I991d1df4be5bf55efec5371b767b332d37dfa3e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217289
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Every AOT user out there has been using bare instructions mode
and continuing to maintaining non-bare instructions mode simply
adds costs (both in terms of time spent making changes to work
in a mode that is not used and CI resources spent on testing it).
This change removes FLAG_use_bare_instructions and changes the code
to assume that FLAG_precompiled_mode implies bare instructions.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,app-kernel-linux-release-x64-try,app-kernel-linux-debug-x64-try
Change-Id: I5032b13bfcb613f79865f2cfa139cca8d1b42556
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/220964
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This extends the existing safepoint operation mechanism by allowing to
perform two different operations:
* "gc safepoint operations": All mutators are stopped at places where
it's safe to GC. It therefore requires stackmaps to be available for
all optimized mutator frames.
* "deopt safepoint operations": All mutators are stopped at places
where it's safe to GC, but also safe to lazy-deopt mutator frames.
It therefore requires deopt-id/deopt-info to be available for all
optimized mutator frames.
Mutators can be asked to block for any of those two safepoint operations.
If a mutator is at a place where its safe to GC it will respond to "gc
safepoint operations" requests, if a mutator is additionally at a place
where it's also safe to lazy-deopt it will respond to "deopt safepoint
operation" requests.
Depending on how the runtime was entered (which is tracked via the
[Thread::runtime_call_deopt_ability_] value) - the mutator might
participate in both or only in gc safepoint operations.
During the start of a "deopt safepoint operation", the safepoint handler
will request all threads to stop at a "deopt safepoint". Some threads
might first want to initiate their own "gc safepoint operation"
(e.g. due to allocation failure) before they reach a "deopt safepoint".
We do allow this by letting the safepoint handler own a "deopt safepoint
operation" but still participate in other thread's "gc safepoint
operation" requests until all mutators are checked into places where
it's safe to lazy-deopt at which point the "deopt safepoint operation"
also owns a "gc safepoint operation".
In order to facilitate this, the Thread's safepoint_state will be
extended to consist of the following bits:
* AtSafepoint
* SafepointRequested
* AtDeoptSafepoint
* DeoptSafepointRequested
* BlockedForSafepoint
Issue https://github.com/dart-lang/sdk/issues/45213
TEST=vm/cc/SafepointOperation_*
Change-Id: Icdc2827718f6780818f99b829a5e806d6bb5b130
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196927
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Right now the vm/cc/CodeRelocator_* tests are written in a strange way
to work around the conservative assumptions the relocator makes.
A future CL will make the relocator insert tramppolines precisely when
they are needed (not conservatively), which will allow writing precise
tests.
TEST=Fixes ARM64 vm/cc/CodeRelocator_* tests
Change-Id: I68f9bcce29f42a2264608f867f177e8f557804fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196666
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The tests generate & run relocated instructions. On ARM64 our macro
assembler uses X15 as stack pointer instead of the normal sp.
-> There was a missing RestoreCSP() in the generation of the call
instructions.
-> It's not an issue for running the test in simulator if CSP is wrong
when returning, though it is for HW.
Adding RestoreCSP() would require the code to be larger, so instead we
use lower level assembly instructions that operate on the normal ARM64
stack.
Closes https://github.com/dart-lang/sdk/issues/45807
TEST=Fixes vm/cc/RelocatinoTest_* on arm64 hw
Change-Id: I0c65e3d22897f536e39f0cf7e9af2be871051b0d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196498
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
There was a missing check for whether a backwards call is out-of-range.
The CL also removes leftover code related to [max_offset_into_target_] -
which wasn't used. The intended use is already over approximated via
[max_instructions_size_].
The CL makes the pc-relative call/tail-call distances pluggable so a
newly added test can modify them for testing in-range/out-of-range
forward/backwards calls.
TEST=vm/cc/CodeRelocator_*
Fixes https://github.com/flutter/flutter/issues/80043
Change-Id: Id4bdb7176108b61235dafb7ffc125da4a2bf07fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195682
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Ryan Macnak