To avoid confusion between the heap size (includes header and rounding up) and number-of-elements size or payload size.
Change-Id: I714c4e8cec92d7ef963de39474d2a1bb23e5b4a3
Reviewed-on: https://dart-review.googlesource.com/c/92400
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
ARM write barrier goes from
ldrne lr, [thr, #+508]
blxne lr
to
blne <offset>
ARM64 write barrier goes from (similarly X64)
beq +8
ldrx lr, [thr, #1056]
blr lr
to
beq +4
bl <offset>
It reduces RX on arm/arm64 by around 0.9%
Though the write barrier wrappers stub has multiple entrypoints (one for
each available register). Because of this, we modify the relocation
logic to support per-call offsets into the target.
To avoid making the assembler code depend on StubCode/FlowGraphCompiler,
we set a closure, which the assembler can call.
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: I9e3d68260cab7ef19ea88f1235c78d6031819d6d
Reviewed-on: https://dart-review.googlesource.com/c/90063
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL adds support to the ImageWriter to write opaque blocks of
trampoline bytes
The AOT code relocator is adapted to allow limited range calls and
inserts trampolines if need be. The algorithm tries to minimize the
number of trampolines added, which for small applications will be 0.
The unconditional pc-relative calls have limited range:
* on ARM (+/-32 MB)
* on ARM64 (+/-128 MB)
To avoid verbose code for doubly-linked list, this CL adds double_list.h
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: I0354cf4b2dd58ed5de25d67fc818f0603a2ec501
Reviewed-on: https://dart-review.googlesource.com/c/89283
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This is the final CL which adds a new --use-bare-instructions flag to
the VM.
If this flag is set during AOT compilation, we will:
* Build one global object pool (abbr: GOP) which all code objects
share. This gop will be stored in the object store. The PP register
is populated in the enter dart stub and it is restored when
returning from native calls.
* Gets rid of the CODE_REG/PP slots from the dart frames. Instead the
compiled code uses the global object pool, which is always in PP.
* Starts emitting pc-relative calls for calls between two dart
functions or when invoking a stub.
Limitation: We only emit pc-relative calls between two code objects
in the same isolate (this is because the image writer is writing
instruction objects for vm-isolate/main-isolate seperately)
* We do compile-time relocation of those static calls after the
precompiler has finished its work, but before writing the snapshot.
This patches all the instruction objects with pc-relative calls to
have the right .text distance.
* We emit a sorted list of code objects in ObjectStore::reverse_code_table,
which will be used by the AOT runtime to go back from PC to Code
objects (where all metadata, e.g. stack maps, catch entry moves, pc
descriptors are available).
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: I6c5dd2b1571e3a889b27e804a24c2986c71e03b6
Reviewed-on: https://dart-review.googlesource.com/c/85769
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Start ordering instructions before writing them out in AOT snapshots.
This is done by:
* discovery of relevant code objects
* ordering of the code objects (currently simply discovery order)
* relocate any pc-relative calls by patching up pc-relative calls with
the actual distance
* producing image writer commands which tell it in which order and at
which .text offsets to write out instructions
Note: Our compiler currently does not emit any pc-relative calls. This
will be added later on.
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: I0153c32a7427ea395e80489efadd5513fe7ca371
Reviewed-on: https://dart-review.googlesource.com/c/85745
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Liam Appelbe