This is a no-op since RBE is not enabled anywhere yet.
Bug: b/296994239
Change-Id: I2d39419736fca0382a6082f6be64e787348bb825
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336440
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
Bug: b/296994239
Change-Id: I179cc7729846885ee952d26082a1e615a46a30b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331923
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This reverts commit 9a11fe517c.
Reason for revert: broke the build for some users.
Original change's description:
> [infra] Begin RBE Linux x64 support.
>
> Bug: b/296994239
> Change-Id: I0ddf9a1beb2996ac67b59779b8b8113432434786
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331282
> Reviewed-by: William Hesse <whesse@google.com>
> Commit-Queue: Jonas Termansen <sortie@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
Bug: b/296994239
Change-Id: Id70259b9357790581f11f105516ff0c6c63ab1ac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331780
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Bug: b/296994239
Change-Id: I0ddf9a1beb2996ac67b59779b8b8113432434786
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331282
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Thomas <athom@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>
This reverts commit e961aa565e.
Reason for revert: does not actually work
Original change's description:
> [vm/build] Workaround for ld 2.19 crash on ARM
>
> When producing ARM builds instruct llvm-objcopy to drop .ARM.exidx/extab
> sections. These sections don't contain any useful information (we don't use
> exceptions or unwind C++ frames and most of the dart binary is in fact not
> covered by them), however they have been seen to break dynamic linker in older
> glibc versions (pre 2.23) because .ARM.exidx ends up being positioned between
> .rel.dyn and .rel.plt sections while older versions of dynamic linker
> expect these two sections to appear one after another in the ELF file.
>
> Closes https://github.com/dart-lang/sdk/issues/41644.
>
> Change-Id: I0ceebb63105591f132f3764180ae041366cbcade
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175723
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,kustermann@google.com,rmacnak@google.com,alexmarkov@google.com
Change-Id: Ia797d8bb6e5dbc44bf68965320da1e03ece17052
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175727
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
When producing ARM builds instruct llvm-objcopy to drop .ARM.exidx/extab
sections. These sections don't contain any useful information (we don't use
exceptions or unwind C++ frames and most of the dart binary is in fact not
covered by them), however they have been seen to break dynamic linker in older
glibc versions (pre 2.23) because .ARM.exidx ends up being positioned between
.rel.dyn and .rel.plt sections while older versions of dynamic linker
expect these two sections to appear one after another in the ELF file.
Closes https://github.com/dart-lang/sdk/issues/41644.
Change-Id: I0ceebb63105591f132f3764180ae041366cbcade
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175723
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
This reverts commit 8ee7a97651.
Reason for revert: lld optimization level -Wl,-O1 appears to either
have a regression or to confuse Golem binary comparison tool.
Original change's description:
> [infra] Roll clang toolchain forward
>
> Change-Id: I41afe48f2fdc056436b58dc8158c62e9207cc43f
> Reviewed-on: https://dart-review.googlesource.com/32140
> Commit-Queue: Zach Anderson <zra@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
TBR=whesse@google.com,rmacnak@google.com,zra@google.com,athom@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I36ec03150a22f89c4cb5371dd1bf43df8a6f16f6
Reviewed-on: https://dart-review.googlesource.com/32800
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Change-Id: I41afe48f2fdc056436b58dc8158c62e9207cc43f
Reviewed-on: https://dart-review.googlesource.com/32140
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This CL switches the ia32 and arm64 builds to use clang by default.
The arm build can't be switched at least until we roll clang to
pick up the fix for https://reviews.llvm.org/D34691.
This CL also changes to use the sysroots from wheezy (and jessie
for arm64) by default so that we can be building/testing locally with
the same setup as we are shipping in the SDK.
Change-Id: I09a1907ee7f78c3f4bb8d56ffdbbd6107ed054d9
Reviewed-on: https://dart-review.googlesource.com/25160
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Build spuriously worked after initial roll due to stale files hanging
around longer than they should have. This CL relands and updates
(hopefully) all the necessary paths.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/3010023002 .
This has a few advantages:
- We can track dependencies more precisely
- ninja can assemble things in parallel as they're ready rather than
sequentially all at once.
- It is easier to customize SDKs depending on target platform, e.g.
Fuchsia.
This CL also has a number of cleanups:
- Defining is_fuchsia and is_fuchsia host so we don't always have to check
- Piping through toolchain overrides in more places
- Fixing bugs in copy_tree.py, not using list_files.py, which is broken on Windows
related #29558R=whesse@google.com
Review-Url: https://codereview.chromium.org/2848943003 .
Flutter uses the same clang toolchain as Fuchsia. This CL puts Dart
on that toolchain, as well. This roll should entail no changes to
glibc version requirements on Linux.
The Fuchsia buildtools distribute clang-format with the toolchain
rather than separately, so this CL introduces forwarding scripts
that are copied to the right place under //buildtools.
This CL sets the default for the number of workers in //tools/gn.py
to 1, as the newer GN version fails occasionally when run
concurrently with other invocations.
As Flutter does, this CL uses the clang toolchain to build for
Android. Thus, it is now possible to build for Android on MacOS.
This change is a prerequisite for assembling the SDK in GN
rather than with a python script:
https://codereview.chromium.org/2848943003/
and will be nicer for making prebuilt SDKs for Fuchsia.
Resubmitting this with the following fixes:
1. Rolls further forward to get past a GN bug
2. Fixes the Android build.
3. Style cleanups in gn.py
Review-Url: https://codereview.chromium.org/2858873005 .
This reverts commit 6bf2c800fd.
There is still some strangeness with the new GN binary not wanting
to do an incremental build on top of a build that used an old GN
binary.
Review-Url: https://codereview.chromium.org/2861903002 .
Flutter uses the same clang toolchain as Fuchsia. This CL puts Dart
on that toolchain, as well. This roll should entail no changes to
glibc version requirements on Linux.
The Fuchsia buildtools distribute clang-format with the toolchain
rather than separately, so this CL introduces forwarding scripts
that are copied to the right place under //buildtools.
This CL sets the default for the number of workers in //tools/gn.py
to 1, as the newer GN version fails occasionally when run
concurrently with other invocations.
As Flutter does, this CL uses the clang toolchain to build for
Android. Thus, it is now possible to build for Android on MacOS.
This change is a prerequisite for assembling the SDK in GN
rather than with a python script:
https://codereview.chromium.org/2848943003/
and will be nicer for making prebuilt SDKs for Fuchsia.
Review-Url: https://codereview.chromium.org/2855283002 .
This reverts commit cc968ca45b.
This CL will have to be relanded in two pieces so that the
update to tools/gn.py lands before the unmodified version
can invoke the updated GN binary.
Review-Url: https://codereview.chromium.org/2855973006 .
Flutter uses the same clang toolchain as Fuchsia. This CL puts Dart
on that toolchain, as well. This roll should entail no changes to
glibc version requirements on Linux.
The Fuchsia buildtools distribute clang-format with the toolchain
rather than separately, so this CL introduces forwarding scripts
that are copied to the right place under //buildtools.
This CL sets the default for the number of workers in //tools/gn.py
to 1, as the newer GN version fails occasionally when run
concurrently with other invocations.
As Flutter does, this CL uses the clang toolchain to build for
Android. Thus, it is now possible to build for Android on MacOS.
This change is a prerequisite for assembling the SDK in GN
rather than with a python script:
https://codereview.chromium.org/2848943003/
and will be nicer for making prebuilt SDKs for Fuchsia.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2854583002 .
toolchain_prefix was not correctly propagated everywhere it needed to
go. This CL also adds an error to build.py if someone tries to use
--toolchain as it is not supported there.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2797303005 .
This change:
- Sucks in gn binaries
- Sucks in a version of llvm that the GN build likes
- Adds tools/gn.py to invoke gn
- Adds a root BUILD.gn and .gn file
- Removes chrome boilerplate we don't need
- etc.
This lets us do a standalone build of the 'runtime'
target for x64, ia32, arm, arm64, mips, and the
simulators on Linux, and arm and arm64 on Android.
It does not include tcmalloc, and hasn't been tested
on Mac or Windows. That work and more cleanup of
chrome boilerplate will come in follow-up CLs.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2350583002 .
