mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 02:33:06 +01:00
71ab5028de
Differential Revision: https://www.youtube.com/watch?v=RsL0cipURA0
85 lines
3.6 KiB
ReStructuredText
85 lines
3.6 KiB
ReStructuredText
===================================================================
|
|
How To Build On ARM
|
|
===================================================================
|
|
|
|
Introduction
|
|
============
|
|
|
|
This document contains information about building/testing LLVM and
|
|
Clang on an ARM machine.
|
|
|
|
This document is *NOT* tailored to help you cross-compile LLVM/Clang
|
|
to ARM on another architecture, for example an x86_64 machine. To find
|
|
out more about cross-compiling, please check :doc:`HowToCrossCompileLLVM`.
|
|
|
|
Notes On Building LLVM/Clang on ARM
|
|
=====================================
|
|
Here are some notes on building/testing LLVM/Clang on ARM. Note that
|
|
ARM encompasses a wide variety of CPUs; this advice is primarily based
|
|
on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips.
|
|
|
|
#. The most popular Linaro/Ubuntu OS's for ARM boards, e.g., the
|
|
Pandaboard, have become hard-float platforms. There are a number of
|
|
choices when using CMake. Autoconf usage is deprecated as of 3.8.
|
|
|
|
Building LLVM/Clang in ``Release`` mode is preferred since it consumes
|
|
a lot less memory. Otherwise, the building process will very likely
|
|
fail due to insufficient memory. It's also a lot quicker to only build
|
|
the relevant back-ends (ARM and AArch64), since it's very unlikely that
|
|
you'll use an ARM board to cross-compile to other arches. If you're
|
|
running Compiler-RT tests, also include the x86 back-end, or some tests
|
|
will fail.
|
|
|
|
.. code-block:: bash
|
|
|
|
cmake $LLVM_SRC_DIR -DCMAKE_BUILD_TYPE=Release \
|
|
-DLLVM_TARGETS_TO_BUILD="ARM;X86;AArch64"
|
|
|
|
Other options you can use are:
|
|
|
|
.. code-block:: bash
|
|
|
|
Use Ninja instead of Make: "-G Ninja"
|
|
Build with assertions on: "-DLLVM_ENABLE_ASSERTIONS=True"
|
|
Local (non-sudo) install path: "-DCMAKE_INSTALL_PREFIX=$HOME/llvm/install"
|
|
CPU flags: "DCMAKE_C_FLAGS=-mcpu=cortex-a15" (same for CXX_FLAGS)
|
|
|
|
After that, just typing ``make -jN`` or ``ninja`` will build everything.
|
|
``make -jN check-all`` or ``ninja check-all`` will run all compiler tests. For
|
|
running the test suite, please refer to :doc:`TestingGuide`.
|
|
|
|
#. If you are building LLVM/Clang on an ARM board with 1G of memory or less,
|
|
please use ``gold`` rather then GNU ``ld``. In any case it is probably a good
|
|
idea to set up a swap partition, too.
|
|
|
|
.. code-block:: bash
|
|
|
|
$ sudo ln -sf /usr/bin/ld /usr/bin/ld.gold
|
|
|
|
#. ARM development boards can be unstable and you may experience that cores
|
|
are disappearing, caches being flushed on every big.LITTLE switch, and
|
|
other similar issues. To help ease the effect of this, set the Linux
|
|
scheduler to "performance" on **all** cores using this little script:
|
|
|
|
.. code-block:: bash
|
|
|
|
# The code below requires the package 'cpufrequtils' to be installed.
|
|
for ((cpu=0; cpu<`grep -c proc /proc/cpuinfo`; cpu++)); do
|
|
sudo cpufreq-set -c $cpu -g performance
|
|
done
|
|
|
|
Remember to turn that off after the build, or you may risk burning your
|
|
CPU. Most modern kernels don't need that, so only use it if you have
|
|
problems.
|
|
|
|
#. Running the build on SD cards is ok, but they are more prone to failures
|
|
than good quality USB sticks, and those are more prone to failures than
|
|
external hard-drives (those are also a lot faster). So, at least, you
|
|
should consider to buy a fast USB stick. On systems with a fast eMMC,
|
|
that's a good option too.
|
|
|
|
#. Make sure you have a decent power supply (dozens of dollars worth) that can
|
|
provide *at least* 4 amperes, this is especially important if you use USB
|
|
devices with your board. Externally powered USB/SATA harddrives are even
|
|
better than having a good power supply.
|