[llvm-dev] [RFC] RISC-V backend

[Alex Bradbury via llvm-dev]

On 17 August 2016 at 10:14, Alex Bradbury <asb at asbradbury.org> wrote:
> The current status is that I have submitted a series of 10 patches
> implementing assembler support and an initial set of relocations and fixups.
> Help reviewing these would be very welcome, do let me know if you'd like to be
> CCed in or added as a reviewer to future patches. I'd ultimately like the
> RISC-V backend to be considered a "reference" backend, and as such
> I specifically welcome reviews you might worry are pedantic.
>
> Please find the current set of patches for your review here:
> * <https://reviews.llvm.org/differential/?authors=asb>

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
<http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html>.
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
middle-end.
* 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?

Best,

Alex