RISC-V support
A few people have asked about support for the RISC-V architecture. Currently GHC has no support for RISC-V. There are two ways it could be added:
Via the LLVM backend
This is likely the easiest. In fact, for a while I thought it would be trivial. Essentially all that is needed is:
- map the STG registers onto the RISC-V machine registers (see
MachRegs.h) - add a few cases to the build system
- add support for GHC's calling convention into LLVM
I have a (very old) branch which does most of (1) and (2).
It turns out that (3) is problematic on RISC-V due to how the backend is implemented. Whereas all other platforms supported by GHC use LLVM's Tablegen mechanism to represent the calling convention mapping (e.g. https://github.com/llvm-mirror/llvm/blob/40bcb88e84e914cfe09f5606987f1fd090ea0dd8/lib/Target/AArch64/AArch64CallingConvention.td#L262), the RISC-V backend took a much different direction (it's been a while since I have looked at this but I vaguely recall that the calling convention was rather tightly coupled with instruction selection; perhaps look at https://github.com/llvm-mirror/llvm/blob/40bcb88e84e914cfe09f5606987f1fd090ea0dd8/lib/Target/RISCV/RISCVISelLowering.cpp).
Writing a native code generator
Currently GHC has three NCG backends: x86, PowerPC, and SPARC. Adding a RISC-V backend would be a great project for someone.
Relates to
- #23179
Activity
added needs triage label
added Tfeature request label
removed needs triage label
How does the LLVM backend compare performance-wise to the NGCs found in GHC?
Would it make sense to switch all backends to LLVM, so that GHC uses only LLVM for code generation like Rust does?
LLVM supports several architectures for which GHC has no NGC, these include MIPS, S390x, SPARC64 (although there is an out-of-tree NGC for SPARC64: https://github.com/jrtc27/ghc/commits/rebased), RISCV and some obscure targets.
Making the LLVM backend more prominent in GHC would make adding new targets easier, similar to the Rust compiler where adding a new architecture is relatively easy once LLVM supports it.
Hey @trac-glaubitz ,
I'm not sure if this still matters to you, but your questions are discussed in a blog post by @AndreasK : https://andreaspk.github.io/posts/2019-08-25-Opinion%20piece%20on%20GHC%20backends.html
Hi @supersven!
Thanks for the links, the discussion is very interesting.
I'm not against the NGC backends per se, but I think LLVM is a very nice alternative for those targets for which an NGC backend may never materialize due to lack of porters.
Would be great if MIPS, S390x and SPARC could get better and faster code generation support through LLVM for GHC.
There is even an LLVM backend for M68k being worked on and to be merged in the near future, so even the venerable 68000-based computers like the Amiga or Atari could get a fast GHC backend (currently we're using the unregisterised backend for these targets).
I'll have a look at what @schwab has contributed for RISC-V and see if there is a way I can get that to work for MIPS, S390x and SPARC (and eventually M68k) as well.
-
Hey @trac-glaubitz ,
LLVM support is indeed much better than unregistered...
What's special about the RISC-V/LLVM target is that it's calling convention is written in C++, usually the LLVM code is generated from a template. So, for the general case AArch64 might be a better example.
-
I found this section in the LLVM documentation to be helpful to "decrypt" the calling convention templating: https://llvm.org/docs/WritingAnLLVMBackend.html#calling-conventions
-
Hey @trac-glaubitz ,
Looks like there already is a NCG for SPARC. According to @AndreasK 's blog post this should (in general) be faster in compiling than a LLVM solution - Maybe, that's exactly what you want for a packaging infrastructure?
There are register mappings for s390x in
master: https://gitlab.haskell.org/ghc/ghc/-/blob/cf3c3bcd93b3a515f3c2db81b5a7c42af480c9b6/includes/stg/MachRegs.h#L594 So, I would expect that you can use this architecture with LLVM: fd8b666a (Commit:Implement s390x LLVM backend.)I would happily volunteer for GHC/LLVM/MIPS, but we should first make sure that's what the GHC project needs/wants. (I found this commit where MIPS registered support was removed: 7b594a5d)
@bgamari , what do you think?
mentioned in issue #14903 (closed)
Darko Stefanovic wrote me asking about the status of this. Quoting my reply below:
Hi Darko,
I had indeed played around with using GHC's LLVM backend to target RISC-V. The state of things is described in the tracking ticket [0]. At the time I was looking at this LLVM's own support for RISC-V was quite immature (and not yet upstreamed); unsurprisingly, I quickly ran into code generation bugs and put the project aside.
Since then LLVM's RISC-V support has improved considerably. The missing piece for GHC support is support for the ghccc calling convention. On most architectures this calling convention definition is fairly trivial [1] since calling conventions are generally defined via TableGen.
Unfortunately, this is not the case for the now-upstream RISC-V which rather seems to define the majority of its calling convention logic in its instruction lowering implementation [2]. It's possible that it wouldn't be that hard to add ghccc support here but I've not looked closely enough to know.
It would be great if someone could pick this project up (or even better, implement a GHC native code generator backend for RISC-V, something that might make for an interesting project for an interested student). I would be happy to point an interested contributor in the right direction to get started.
Cheers,
- Ben
[0] #16783 (closed)
Edited by Ben Gamari-
That's the register mapping @bgamari came up with (https://gitlab.haskell.org/ghc/ghc/-/blob/wip/riscv/includes/stg/MachRegs.h):
/* ----------------------------------------------------------------------------- The RISC-V 64 register mapping (RV64MD) RISC-V registers (see Section 2.1 in RISC-V User-Level ISA V2.1) RISC-V ABI STG name name name Saver RISC-V usage x0 zero - Constant 0 x1 ra Caller Return address x2 sp Sp Callee Stack pointer x3 gp Base ? Global pointer x4 tp Hp ? Thread pointer x5 t0 R1 Caller Temporaries x6 t1 R2 Caller Temporaries x7 t2 R3 Caller Temporaries x8 s0/fp SpLim Caller Saved register/frame pointer x10 a0 R4 Caller Function arguments/return values x11 a1 R5 Caller Function arguments/return values x12 a2 R6 Caller Function arguments/return values f0 ft0 D1 Caller FP temporaries f1 ft1 D2 Caller FP temporaries f2 ft2 D3 Caller FP temporaries f3 ft3 D4 Caller FP temporaries f4 ft4 F1 Caller FP temporaries f5 ft5 F2 Caller FP temporaries f6 ft6 F3 Caller FP temporaries f7 ft7 F4 Caller FP temporaries Following x86-64's model we use caller-saves registers. ----------------------------------------------------------------------------- */ #elif MACHREGS_riscv64 #define REG(x) __asm__(#x) #define REG_Base x3 #define REG_Sp x2 #define REG_Hp x4 #define REG_R1 x5 #define REG_R2 x6 #define REG_R3 x7 #define REG_SpLim x8 #define REG_R4 x10 #define REG_R5 x11 #define REG_R6 x12 #define REG_F1 f4 #define REG_F2 f5 #define REG_F3 f6 #define REG_F4 f7 #define REG_D1 f0 #define REG_D2 f1 #define REG_D3 f2 #define REG_D4 f3PS: I added this to the ticket because I think that's the core of the calling convention topic: How GHC maps it's registers and how these are mapped by LLVM. I already started to wrap my head around the LLVM part and will pick it up as next task (if no-one else is faster
Edited by Sven Tennie assigned to @supersven
mentioned in merge request !4269 (closed)
mentioned in merge request !4327 (closed)
-
When it rains, it pours! It seems like we may now have two distinct efforts in this direction. @supersven is working in !4269 (closed) and @schwab is working on !4327 (closed). We should coordinate to ensure that we don't repeat work.
@supersven, @schwab: What are the statuses of your respective efforts?
-
My status is way not as far as @schwab 's: I ported the changes of @bgamari 's old branch to latest master (so you can configure risc-v as a target) and digged a bit into the LLVM/Calling Convention topic, but I've no finished branch. So, I would drop my approach in favour of @schwab 's.
I'd like to offer my help with the GHC-side code review and testing.
@schwab are you planning to write a Native Code Generator, too? Otherwise I would head over to this ...
Finally: Congrats, great work, @schwab !
I have no plans to write a NCG.
Edited by Andreas Schwab
It has been tested with ghc 8.10.2 and a backport to llvm 9.0.1.
https://build.opensuse.org/project/monitor/home:Andreas_Schwab:riscv:ghc
-
@schwab ,
Have you already tried to run the testsuite? Skimming over the SuSE spec file (https://build.opensuse.org/package/view_file/home:Andreas_Schwab:riscv:ghc/ghc/ghc.spec) it looks like that's not done by the build script (it only executes
make installand later compiles a very simple Haskell file).
mentioned in issue #16882 (closed)
mentioned in merge request !5471 (closed)
Hello, great to see work being done on a (Linux) RISC-V support. I see riscv64 being mentioned couple of times but "riscv32" is nowhere to be found. Does "riscv" support implicitly means both "riscv32" and "riscv64" since @schwab's implementation uses the LLVM backend? If not, is a "riscv32" port made easier by this "riscv64" work?
-
Hello, great to see work being done on a (Linux) RISC-V support. I see riscv64 being mentioned couple of times but "riscv32" is nowhere to be found. Does "riscv" support implicitly means both "riscv32" and "riscv64" since @schwab's implementation uses the LLVM backend? If not, is a "riscv32" port made easier by this "riscv64" work?
RV64 support no doubts eases RV32 support. However, I am almost certain that further work will be necessary. @schwab, do you have a sense of what would be involved here?
Folks, I'm trying to get excellent Andreas (@schwab ) work of registerised/llvm ghc working on Debian unstable. Debian provides GHC 8.8.4 as unregisterised compiler on riscv64 platform. First of all, I needed to bootstrap ghc 8.10.x. This is possible and to get unregisterised compiler quite easily if one apply @bgamari recommended patch from: #19965 (closed) and one also needs to workaround issue of not linking libatomic to rts libraries. Partial fix by Ben is in #18928 -- it's however incomplete for make based build. I'm preparing its updated version (for head) and hopefully submit shortly. Andreas also warns that for building recent head with unregisterised compiler (e.g. unregisterised building registerised) one needs this patch: !4331 (diffs). -- this is to be applied to head if I understand that well. So my status so far is: ghc 8.10.7 unregisterised built on debian and the compiler is able to built libraries well (e.g. -latomic is linked well). But when trying to build head using llvm-12 (provided by debian) and ghc 8.10.7 as a bootstrap compiler (and with Andreas recommended patch applies) I still get crashing ghc-stage2:
"inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -hide-all-packages -package-env - -i -iutils/check-ppr/. -iutils/check-ppr/dist-install/build -Iutils/check-ppr/dist-install/build -iutils/check-ppr/dist-install/build/check-ppr/autogen -Iutils/check-ppr/dist-install/build/check-ppr/autogen -optP-include -optPutils/check-ppr/dist-install/build/check-ppr/autogen/cabal_macros.h -package-id base-4.16.0.0 -package-id bytestring-0.11.1.0 -package-id containers-0.6.4.1 -package-id directory-1.3.6.1 -package-id filepath-1.4.2.1 -package-id ghc-9.3 -Wall -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -outputdir utils/check-ppr/dist-install/build -c utils/check-ppr/./Main.hs -o utils/check-ppr/dist-install/build/Main.dyn_o ghc-stage2: internal error: evacuate: strange closure type 918375 (GHC version 9.3.20211004 for riscv64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug make[1]: *** [utils/check-ppr/ghc.mk:18: utils/check-ppr/dist-install/build/Main.dyn_o] Aborted make: *** [Makefile:128: all] Error 2so this on on debian unstable. Now, I'm attempting to build head on Andreas reference openSUSE. I'm using this: https://en.opensuse.org/openSUSE:RISC-V in qemu 5.1.0. Will take hours/days till I know more and will report back about it here.
@trac-glaubitz have you tried this on some risc64 platform yourself? Would like to hear about your experience or needed tricks.
Thanks, Karel
I think it helps if the bootstrap compiler is a static-only build, similar to what is built by https://build.opensuse.org/package/show/home:Andreas_Schwab:riscv:ghc/ghc-prepare-binary-distributions: put "GhcLibWays = v" in mk/build.mk.
