[RFC] RISC-V backend

Hi Bekket,

P.S. Apologies if this is not threading, as I’m replying to the digest.


I’m pretty interested in developing RISC-V backend. But the information across mailing list, upstream codebase and the riscv.org<http://riscv.org/> website is a little bit scattered and confused. Here are some facts I’ve known:

  1. Colin has finished a great job on https://github.com/riscv/riscv-llvm <https://github.com/riscv/riscv-llvm>, the riscv-trunk branch is upstreaming with the trunk
  2. There is also a clang frontend on https://github.com/riscv/riscv-clang <https://github.com/riscv/riscv-clang>. I guess the riscv-trunk branch is also upstreaming with the trunk
  3. Alex had submitted some patches for code review. About 7 of them is not accepted yet
  4. Currently the upstream codebase are mostly consist of MC part. Seems that it’s not able to be tested from llc

Yes. You might want to read this thread on the RISC-V mailing list while I was discovering the state of upstream LLVM, Colin’s port and Alex’s patchset:

Colin’s port is against a very old version of LLVM nevertheless it is a substantial body of work. I couldn’t get codegen in Clang to work however it may work with -O0. It obviously takes a lot of effort to track upstream, when the arch is not yet integrated into mainline. Alex’s port is the most up-to-date and I have experimented with Alex’s MC layer tests using llvm-lit. Alex has some follow ups to the RISC-V mailing list on the calling convention with a python tool that is a reference implementation for the calling convention. The calling convention work is required for Clang enablement. I’m not sure if the patches have landed upstream.

Here is the public repo with current patchset which should be applied on top of LLVM upstream (this was the case a 3 months back):

Alex mentioned some infrastructure dependencies for an architecture that supports both 32-bit and 64-bit registers while sharing the same tablegen machine instruction definitions. MIPS currently duplicates tablegen definitions and is not a “reference architecture”. The idea is that RISC-V could become a “reference architecture” in LLVM so one would not duplicate the tablegen definitions for RV64 given most of the ISA definition is shared with RV32. I’m not sure if this capability is in mainline yet. You could look at Colin’s port for Clang enablement however the calling convention has changed and firmed up since the timeframe of Colin’s port.

LLVM has a relatively steep learning curve so I only got so far with my own investigation. I feel I could make progress if I had more time as I am slowly learning bits and pieces about LLVM internals but it would require sustained study of the codebase for a sustained amount of time to become productive.