Build LLVM with RISCV support

[colemancda]

Builds LLVM and Clang with RISCV target enabled, which is not the default. Without this patch I get the following error when trying to compile:

error: unable to create target: 'No available targets are compatible with triple "riscv64-unknown-linux-gnu"'

coleman@hp-laptop:~/Developer/swift-source/swift$ clang --version
clang version 13.0.0 (https://github.com/apple/llvm-project.git 3dade082a9b1989207a7fa7f3975868485d16a49)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
coleman@hp-laptop:~/Developer/swift-source/swift$ clang -print-targets
  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    mips       - MIPS (32-bit big endian)
    mips64     - MIPS (64-bit big endian)
    mips64el   - MIPS (64-bit little endian)
    mipsel     - MIPS (32-bit little endian)
    ppc32      - PowerPC 32
    ppc32le    - PowerPC 32 LE
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

Resolves SR-16005.

[colemancda]

@buttaface Could you review? RISCV is not built by default the way its invoked by the current build presets.

[colemancda]

When configuring llvm with the patches I get

-- Targeting X86
-- Targeting ARM
-- Targeting AArch64
-- Targeting PowerPC
-- Targeting SystemZ
-- Targeting Mips
-- Targeting RISCV

And without the patches

-- Targeting X86
-- Targeting ARM
-- Targeting AArch64
-- Targeting PowerPC
-- Targeting SystemZ
-- Targeting Mips

[colemancda]

Output of clang -print-targets with patches applied:

coleman@hp-laptop:~/Developer/swift-source/swift$ /home/coleman/Developer/swift-source/install/usr/bin/clang -print-targets
  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    mips       - MIPS (32-bit big endian)
    mips64     - MIPS (64-bit big endian)
    mips64el   - MIPS (64-bit little endian)
    mipsel     - MIPS (32-bit little endian)
    ppc32      - PowerPC 32
    ppc32le    - PowerPC 32 LE
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

[finagolfin]

You're right, running that command with the latest official Swift trunk snapshot build for linux shows this arch missing. Let me look into why first.

[finagolfin]

Ah, found it, the Swift default overrides LLVM's defaults with its own default list. You should add RISCV to the default there, rather than trying to override a couple presets here and there.

[colemancda]

@buttaface Thanks, I'll update the patch accordingly.

[colemancda]

@buttaface I updated the PR with the requested changes

[finagolfin]

@gottesmm, would you approve and run the CI?

[finagolfin]

@CodaFi, mind reviewing?

[colemancda]

@MaxDesiatov Could you review please?

[gottesmm]

A few things:

1. If we decide to do this, we should just add RISCV to the given list rather than remove the list entirely. The reason why is that if we remove this list, we will build /all/ LLVM targets, even ones that aren't RISCV. This is an issue since it will increase compile time in the present, but also will cause us to silently build any future LLVM targets that are added. The former is bad, but the latter is even worse since it will lead to silent increases in compile time due to upstream changes which we do not want. Building Swift already takes enough time, so whenever we want to increase the compile time of the project, we should be intentional and look at it as a trade-off not as a thing to do without cost.
2. That being said, if we want to add riscv support to the given list of targets, we should be aware that it will increase compile time for all builds. I think it is important that we measure the compile time increase. Can you do that? Also @shahmishal how much of a compile time budget do we have for this sort of thing?

[colemancda]

A few things:

1. If we decide to do this, we should just add RISCV to the given list rather than remove the list entirely. The reason why is that if we remove this list, we will build /all/ LLVM targets, even ones that aren't RISCV. This is an issue since it will increase compile time in the present, but also will cause us to silently build any future LLVM targets that are added. The former is bad, but the latter is even worse since it will lead to silent increases in compile time due to upstream changes which we do not want. Building Swift already takes enough time, so whenever we want to increase the compile time of the project, we should be intentional and look at it as a trade-off not as a thing to do without cost.
2. That being said, if we want to add riscv support to the given list of targets, we should be aware that it will increase compile time for all builds. I think it is important that we measure the compile time increase. Can you do that? Also @shahmishal how much of a compile time budget do we have for this sort of thing?

@gottesmm With regard to your first point, we are not building all LLVM targets, if you remove llvm-targets-to-build from a build preset, it should use the default value in utils/build_swift/build_swift/driver_arguments.py

  option('--llvm-targets-to-build', store,
            default='X86;ARM;AArch64;PowerPC;SystemZ;Mips;RISCV',
            help='LLVM target generators to build')

in which case we are only adding 1 new target arch.

My first commit (which was rebased) did the approach you suggest, but I changed it so we use the default value instead, so in the future its a single list (besides WASM usage) we need to modify.

[gottesmm]

Ok. I am fine with using the default value. That being said, can you measure how much build time this adds to a clean build?

[DougGregor]

@swift-ci please test

[finagolfin]

@colemancda, a test is failing because you missed updating this line too.

[finagolfin]

@colemancda, just waiting on you to update the test and check the difference in build time, and we can try to get this in.