I was looking at the build graph for RISC-V GHC and wondering why clang is a dependency (rather than just llvm).

LLVMAS should be a "specific LLVM compatible assembler" which needs to understand assembly produced by LLVM. The easiest way to be sure is to use clang from the same version as llc and opt. Note that the naming chosen by GHC is misleading, clang can be used as an assembler, llvm-as converts IR into machine code.

This comment in the Nixpkgs source code doesn't clearly explain why LLVMAS is set to clang and not llvm-as.

The upstream documentation is no better.

Specifically GHC needs to be able to call the opt and llc tools.

Does anyone here know why the build uses clang?

Well, I just got to stage2 in the build with llvm-as and, sure enough, it doesn't work:

llvm-as: Unknown command line argument '-iquotelibraries/ghc-prim/GHC'.  Try: '/nix/store/8cn6305g0gsrczz3ga298k0zilfzgs7r-llvm-20.1.8/bin/llvm-as --help'
llvm-as: Did you mean '--help-list-hidden'?
[...]

Anyway, back on clang, I'm getting many errors in the assembly that GHC generates, e.g.

/build/ghc44067_0/ghc_7.s:11:7: error:
     error: unknown operand
            subq    $40, %rsp
                    ^
   |
11 |         subq    $40, %rsp
   |       ^

I can upload a full log, but I doubt it's very insightful.

It seems that instead of targeting LLVM assembly, it's generating something else?

I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:

1. I set the target stage to 3 (instead of 1).
2. I removed the --host configure flag because the script still complains about "build != host"

I'm not very familiar with x86 assembly, but it does look like x86 assembly. Even though GHC is being explicitly given -fllvm.

I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:

1. I set the target stage to 3 (instead of 1 or 2).
2. I removed the --host configure flag because the script still complains about "build != host"

I'm not very familiar with x86 assembly, but it does look like x86 assembly. Even though GHC is being explicitly given -fllvm.

Is the TH external interpreter supposed to work?

iserv-proxy-interpreter: tmp/nix/store/7kjpbn6fv6gqi9fx65ann5bqdsm3s9fi-riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-linux-ghc-9.10.3/ghc-prim-0.12.0-561f/libHSghc-prim-0.12.0-561f.a: RTS linker not implemented on riscv
iserv-proxy-interpreter: loadArchive "tmp/nix/store/7kjpbn6fv6gqi9fx65ann5bqdsm3s9fi-riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-unknown-linux-gnu-ghc-9.10.3/lib/riscv64-linux-ghc-9.10.3/ghc-prim-0.12.0-561f/libHSghc-prim-0.12.0-561f.a": failed

(Context: fixing the pkgsCross.riscv64.buildPackages.ghc build and trying to cross-compile some Haskell packages)

In reply to @sternenseemann:systemli.org
I guess you may need to amend the default for enableExternalInterpreter