Page MenuHomeFreeBSD

Add support for selectively enabling/disabling LLVM targets
ClosedPublic

Authored by dim on Jun 6 2017, 8:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 13, 11:02 PM
Unknown Object (File)
Sat, Apr 13, 8:25 PM
Unknown Object (File)
Sat, Apr 13, 7:36 PM
Unknown Object (File)
Sat, Apr 13, 5:09 PM
Unknown Object (File)
Fri, Apr 12, 9:37 AM
Unknown Object (File)
Thu, Apr 11, 6:42 AM
Unknown Object (File)
Mar 19 2024, 9:16 AM
Unknown Object (File)
Mar 7 2024, 10:36 AM
Subscribers
None

Details

Summary

This is a first stab at making it possible to select which LLVM targets
you want to build during buildworld. The current list is:

  • MK_LLVM_TARGET_AARCH64
  • MK_LLVM_TARGET_ARM
  • MK_LLVM_TARGET_MIPS
  • MK_LLVM_TARGET_POWERPC
  • MK_LLVM_TARGET_SPARC
  • MK_LLVM_TARGET_X86

To not influence anything right now, all of these are on by default, in
situations where clang is enabled. At a later stage we can add some
magic to only enable the target currently required for the cross-tools
stage, or other fancy things.

Selectively turning a few targets off manually should work. Turning on
only one target should work too, even if that target does not correspond
to the build architecture. (In that case, LLVM_NATIVE_ARCH will not be
defined, and you can only use the resulting clang executable for
cross-compiling.)

It is also possible to disable all targets, which will result in a clang
executable that runs, but cannot compile anything. Fairly nonsensical,
so maybe a seatbelt would be nice.

Note that clang provides no easy way to show the targets it supports, so
I submitted a review upstream to make that possible, which I might
probably add later after it is accepted.

With this, we can also add riscv or systemz support relatively easily,
but turned it off by default, so it does not trip anybody up who does
not ask for it explicitly. :)

Last but not least, I did some measurements on ref12-amd64.freebsd.org,
building clang from scratch, with all targets and with only the x86
target. The latter was ~14% faster in real time (on a 32-core box), and
~17% faster in user time. For a full buildworld the difference will
probably be less pronounced, but I have not measured it explicitly.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Update to add all other targets supported by LLVM:

  • MK_LLVM_TARGET_AMDGPU
  • MK_LLVM_TARGET_BPF
  • MK_LLVM_TARGET_HEXAGON
  • MK_LLVM_TARGET_LANAI
  • MK_LLVM_TARGET_MSP430
  • MK_LLVM_TARGET_NVPTX
  • MK_LLVM_TARGET_RISCV
  • MK_LLVM_TARGET_SYSTEMZ
  • MK_LLVM_TARGET_XCORE

Nice, I have 2 concerns.

Note that clang provides no easy way to show the targets it supports, so
I submitted a review upstream to make that possible, which I might
probably add later after it is accepted.

If a user managed to install a compiler that only had 1 architecture and then tried a cross-build for an arch their compiler did not have, SYSTEM_COMPILER may trigger and fail. Being able to check if the TARGET_TUPLE being compiled for in buildworld is available in CC will be critical here.

  1. Similar to (1), I worry about letting users do this for their target compiler (the one installed). But I really like the idea for using it when building the bootstrap cross-compiler and SYSTEM_COMPILER wasn't able to use /usr/bin/cc. It will help with make universe until I can rework it to build the bootstrap compiler only once.

If a user managed to install a compiler that only had 1 architecture and then tried a cross-build for an arch their compiler did not have, SYSTEM_COMPILER may trigger and fail. Being able to check if the TARGET_TUPLE being compiled for in buildworld is available in CC will be critical here.

Well, cc -v or cc --version already shows the default target:

$ cc -v
FreeBSD clang version 5.0.0 (trunk 304659) (based on LLVM 5.0.0svn)
Target: i386-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

I committed a change upstream to show the registered targets for --version, similar to how these are shown in other llvm tools, but I'm not sure if its output is useful for us. For example:

$ /share/dim/llvm/305145-trunk-freebsd12-i386-ninja-rel-1/bin/clang --version
clang version 5.0.0 (trunk 305145)
Target: i386-unknown-freebsd12.0
Thread model: posix
InstalledDir: /share/dim/llvm/305145-trunk-freebsd12-i386-ninja-rel-1/bin

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    armeb      - ARM (big endian)
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    hexagon    - Hexagon
    lanai      - Lanai
    mips       - Mips
    mips64     - Mips64 [experimental]
    mips64el   - Mips64el [experimental]
    mipsel     - Mipsel
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore

Extracting the information we need from that output might be tricky. Do you have any suggestions?

  1. Similar to (1), I worry about letting users do this for their target compiler (the one installed). But I really like the idea for using it when building the bootstrap cross-compiler and SYSTEM_COMPILER wasn't able to use /usr/bin/cc. It will help with make universe until I can rework it to build the bootstrap compiler only once.

This is just a tryout, to see how feasible it is. There are multiple intentions:

  • Appeasing some users who only care about a single architecture (usually x86), and who don't like to compile code meant for anything else.
  • Adding targets such as SystemZ and RISCV which might be interesting to a limited subset of people, for the sake of experimentation.

The part where you build the bootstrap compiler only once, and use it for different architectures could already be done with the fixed list of targets now supported.

I'm sure it's quite stale now but I'm fine with it...

This revision is now accepted and ready to land.Jun 20 2018, 8:59 PM

Actually my one complaint is that you've added all of these other backends that we don't really support already right? That seems like maintenance burden for no benefit?

  • Rebased against recent head
  • Only add targets which are currently supported
  • Added check for at least one enabled target
  • Use for loop instead of individual target checks
This revision now requires review to proceed.Jun 21 2018, 6:00 PM

I'll make buildworld only build the 1 needed target for the cross-compiler, but leave the defaults otherwise for the target compiler.

This revision is now accepted and ready to land.Jun 21 2018, 7:26 PM
dim retitled this revision from WIP: Add support for selectively turning on LLVM targets to Add support for selectively enabling/disabling LLVM targets.Jun 22 2018, 9:44 AM
This revision was automatically updated to reflect the committed changes.