[RFC] RISC-V backend

Good point. Therefore I'd change my assertion - ideally every
experimental backend would have a silent buildslave, to help those
collaborating on building/maintaining it.


I have just refreshed the whole set of patches, which now address all
review comments received so far. Many thanks to everyone who has taken
the time to review.

I will host a buildslve connected to the 'silent staging buildbot' to
provide public build status once the RISC-V backend starts getting
committed. Additionally, Colin Schmidt and I have submitted a proposal
for a RISC-V related Birds of a Feather session at the 2016 US LLVM
Developers' Meeting. If that is accepted it may be a good venue for
further discussion about more long-term plans.

Does anybody have any other thoughts on the addition of RISC-V to LLVM?



Hey Alex,

even though not being involved in the reviews itself, as an observer it
seems to me you clearly reached your goal as being a "good example" for
a new back end. I think we can keep this discussion and the
corresponding reviews as an example of how to upstream a new back end.
And also how -- as a community -- welcome a new back end. It was a
pleasure to follow this discussion.


Completely agreed. Having now reviewed the patch set, I’m really looking forward to having it land and having an in-tree back end that we can point to as an example of how people should write back ends.

Though I’m interested to see if adding RISC-VC support will make it ugly...


+1 from me too. That may have been obvious from my reviews, but figured it didn’t hurt to say explicitly. :slight_smile:

Hi all, I wanted to share an update on the current status of things.

* https://reviews.llvm.org/D23557 1/10. RISC-V triple parsing code.
Reviewed and ready to land
* https://reviews.llvm.org/D23558 2/10. RISC-V ELF defines. Reviewed
and ready to land
* https://reviews.llvm.org/D23560 3/10. Stub RISC-V backend. Reviewed
and ready to land
* https://reviews.llvm.org/D23561 4/10. Add basic .td files. Reviewed,
but really needs another look from reviewers due to a revised patch
* https://reviews.llvm.org/D23496 Move OperandMatchResultTy to
MCTargetAsmParser. Unreviewed.
* https://reviews.llvm.org/D23562. 5/10. Add bare-bones RISC-V
MCTargetDesc. Reviewed and ready to land.
* https://reviews.llvm.org/D23563 6/10. Add basic RISCVAsmParser.
Review comments addressed, needs acceptance.
* https://reviews.llvm.org/D23564 7/10. Add RISCVInstPrinter and basic
tests. Reviewed and ready to land.
* https://reviews.llvm.org/D23566 8/10. Add support for all RV32I
instructions. Review comments addressed, needs acceptance
* https://reviews.llvm.org/D23567 9/10. Add support for disassembly.
Reviewed and ready to land.
* https://reviews.llvm.org/D23568 10/10. Add fixups and relocations
necessary for %hi, %lo and friends. Awaiting review

So 6 are reviewed and ready to land, 3 have started the review process
and awaiting signoff, and 2 remain unreviewed. Many thanks to everyone
who has chipped in with review comments, the patches have improved
significantly as a result.

If you would like to help, but poring through backend code doesn't
appeal to you, it would be really great to:
1) Review this minor patch that moves the definition of
OperandMatchResultTy to a header rather than in tblgenned code
2) Check out the discussion about variable-sized register classes. It
raises lots of interesting questions, and an improvement to LLVM here
could benefit multiple backends, including RISC-V
I'm not blocked on this, but would prefer to use something like this
proposal to avoid having to define every instruction twice (once for
RV32, again for RV64).

I'm really pleased that I'll be able to make it over to the US LLVM
Developers' Meeting in November. The BoF submission Colin and I put in
sadly wasn't accepted, but perhaps a few people may be interested in
having the sort of discussion we proposed in a more informal setting
(i.e. the 'corridor track' - just say hi!):

* The open nature of RISC-V gives a unique opportunity to contribute
to its development. How can we, as compiler engineers best contribute
our expertise to this effort?
* How can we rapidly achieve first-class RISC-V support across LLVM projects?
* What can we do to make LLVM more accessible to groups performing
computer architecture research using RISC-V?
* Are there lessons to be learned from the history of other
architectures in LLVM, mistakes that we can avoid?
* What can we do to track improvements (or regressions) in performance
and code size over time?
* Are there areas where the RISC-V community can contribute to the
general LLVM infrastructure? e.g. moving target-specific passes to the
* There is a potential for a large diversity in RISC-V implementations
with support for different instruction set subsets or new custom
instructions. How can LLVM deal with this?




I’m pretty interested in developing RISC-V backend. But the information across mailing list, upstream codebase and the 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, the riscv-trunk branch is upstreaming with the trunk
  2. There is also a clang frontend on 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

Please correct me if I’m wrong.

My question is:

  1. Probably the biggest one: What’s next step? I’m neither the expert of RISCV nor good at backend development so I’m afraid I can’t review the patches. But I’m willing to develop the ISel and scheduling part. Is helping to port the work from Colin’s github repo to upstream codebase a good starting point?
  2. What’s the clang’s status? I know it’s a little bit weird to ask in this mailing list but Colin’s work on github seems to be paused and there is no patches submitted to the code review, I just want to know whether helping to port the work from github to upstream would also be a good idea.

Best Regards,
Bekket McClane