Compiler options for hacking the default target on RISC-V

Learn
1

I’m trying to built the GHC for RISC-V with default target set to the extension set rv64g or rv64imafd. Currently it is set to rv64gc, ie, with support for compressed instructions. But I am working on a custom CPU that doesn’t support compressed instructions.

I found this article on hacking the build. However, I am still confused as to how set the target options. For example, on the GNU toolchain, building by passing --with-arch=rv64g or on Clang, modifying the source code achieves this.

The best I could find on the source tree was by using grep:
llvm-targets:,("riscv64-unknown-linux-gnu", ("e-m:e-p:64:64-i64:64-i128:128-n64-S128", "", "+m +a +f +d +c +relax"))

I am guessing this is for when llvm is used as backend.

Other than this, I haven’t found any references where I could make modifications in source code or any build flags that would help. Any help on this would be greatly appreciated.

4 Likes
2

I can’t help you with your questions, but i’m curious about your experience with GHC and surrounding tooling on RISCV (Template Haskell, GHCi, Cabal etc.). I have a Starfive Visionfive2 lying around, which i plan to reactivate at some point.

3

Hey @malteneuss :waving_hand:

Your board should be fully supported by GHC versions >= 9.12. We had a critical bugfix lately, so you may even want to try master.

Unfortunately, we’re not providing binary distributions, yet. So, you’d have to build it yourself.

And, be prepared that the experience will be very slow… :smiley:

1 Like
4

@supersven thanks for the info, and many thanks for driving the RISCV support of GHC. Do you happen to have a working Nix(OS) setup? Ideally, cross-compilation to RISCV or native compilation on the board would be great to not have to tinker with manual steps. The Visionfive 2 board already has good NixOS support: nixos-hardware/starfive/visionfive/v2 at master · NixOS/nixos-hardware · GitHub

5

Hey @oakmacaroon :waving_hand:

Out of interest (it’s not important for the solution to your issue), could you please tell us which SOC/CPU you’re using and why? I suspect this might be a rather exciting story!

The documentation you’re referring to is unfortunately pretty outdated; at least it doesn’t apply to GHC versions which are using Hadrian as build system (I guess - without having it looked up >= 9.6.)

In general, changing the target ISA is not a supported feature. However, you might have luck with some hacking involved.

The tricky bit is that all intermediate compilers (LLVM IR, C and Assembly) may emit code (or object code in case of Assembly) that may lead to compressed instructions. They may have a default target which is not yours. So, it’s best to tell them precisely which target you want.

For obvious reasons, it’s also not good enough to just apply these changes to an existing GHC installation as you need to have libraries and the RTS be compiled for the specific target as well.

For my ongoing work on support for the V(ector) extension, I wrote this hacky Hadrian flavour transformer to accomplish this: !13467: Draft: RISC-V vectors · Merge requests · Glasgow Haskell Compiler / GHC · GitLab . You could probably create a new Flavour for this as well.

And, also ran the autoconf scripts as CFLAGS=-march=rv64gv ./configure.

Then, you could try to change llvm-targets as you considered. Or, try to use the NCG, if you’re using GHC 9.12 (as there’s an unreleased bugfix, master would be a good choice then.) AFAIK there are no explicit compressed instructions used in the NCG. However, there may be surprises regarding other extensions as we never tested the NCG to be limited to a specific instruction set.

Gaining visibility how the underlying tools are called is probably key to this endeavor. For GCC and GAS you could e.g. try -optc=-v -opta=-v.

I hope this helps. Please let me know when you’re stuck or have more questions.

6

The easiest way to get a precompiled GHC binary (and happy and alex) for RISC-V is using Debian trixie or sid (well, Armbian, and I guess Ubuntu). As of now that is 9.6.6, and at least the version that I’ve used about half a year ago (9.6.4?) worked on RISC-V64 hardware (and in Qemu), not just the compiler, but also building the “usual” stuff. You can than use that to build a more recent GHC without problems, I’d guess (that had been my plan, but in the end I didn’t do that).

1 Like
7

Some statistics: on my SpacemiT K1 (8 Cores, 8GB RAM, SSD), a Banana Pi BPI-F3, building and installing (including documentation) GHC 9.12.1 takes about 17 hours.

A minimal Cabal executable + library needs 45 seconds on the first compile and about 14s when changing something in the library (so the executable has to be rebuild too).

GHC 9.6.6 as provided by Debian is significantly slower: 60s and 35s

1 Like
8

@ReleaseCandidate Thanks for posting these numbers. :+1: (These are about what I’m used to as well. Though, I never really measured.)

The huge gap between GHC 9.12 and GHC 9.6 is likely due to GHC 9.12 providing its own code generation backend (which is used by default) while 9.6 only provides a LLVM backend which is known to be slower.

1 Like
9

openSUSE Tumbleweed has port for risc-v ghc-9.10.x with back ported riscv64 ncg