[llvm-dev] RISC-V LLVM status update

[Alex Bradbury via llvm-dev]

As you will have seen from previous postings, I've been working on upstream
LLVM support for the RISC-V instruction set architecture. The initial RFC
<http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html>
provides a good overview of my approach. Thanks to funding from a third party,
I've recently been able to return to this effort as my main focus. Now feels
like a good time to give an update on where the RISCV backend is at, and how
you can help.

## Current status
* A full, regularly rebased patchset can be found here
<https://github.com/lowRISC/riscv-llvm>.
* 16 of these patches have been put up for review so far. 7 have been
committed, and 8 are awaiting review.
* The vast majority of the GCC torture suite compiles and runs at O0,
targeting RV32I. 1315 out of 1352 compile and run (32 compile-time failures, 5
run-time failures).
* I intend to keep <http://www.lowrisc.org/llvm/status> updated with status,
test results etc.

## Next steps and getting involved
The plan has always been to work from the MC-layer upwards towards reliable
RV32I codegen. This then provides a stable 'core' of the backend where it's
easy for further development work to be parallelised, and for others to make
contributions. I think we're now at that point.

I would really like to avoid setting up a new 'downstream', and to use this
opportunity to pull in new people to upstream LLVM development.  However
collaboration is made rather difficult for now due to the large gap between
the patches that have been reviewed and committed upstream vs the complete
patchset. If you would like to help, reviewing the remaining patches
<https://reviews.llvm.org/differential/?authors=asb&order=updated> is an
incredibly valuable way to do so. If you would like to be listed as a reviewer
for future patches, just let me know (and feel free to add yourself for
existing patches). I'll be doing some refactoring of RISCVInstrInfo.td as
discussed here
<http://lists.llvm.org/pipermail/llvm-dev/2017-August/116635.html>, but this
is a straight-forward non-functional change. Other than that, there are no
planned changes to the patches currently up for review.

My current plans look like the below, though of course will accelerate
significantly with more contributors:
* Next 2-3 weeks: resolve remaining torture suite issues, ABI compliance
testing, documentation on MC layer backend implementation
* End of Oct: Clang toolchain driver, initial MAFD MC layer + codegen +
calling conventions, initial benchmarking vs RISC-V GCC and generated code
quality improvements
* End of Dec: finalise MAFD support, improve MAFD compliance testing and
larger-scale codegen testing, further expanded backend docs, generated code
quality improvements

I've mapped out a number of TODO items here
<https://github.com/lowRISC/riscv-llvm/issues>, which I hope can help to
co-ordinate efforts. Where possible, this indicates the current preferred
approach (e.g. we plan to provide RV64 support building upon Krzysztof's
variable-sized register class work). I've submitted a RISC-V BoF session
proposal for the upcoming LLVM Dev Meeting. If accepted, this should provide a
great opportunity to further discuss and co-ordinate work between the multiple
parties who have expressed an interest.

## Credits and support
Thank you to everyone who has contributed review comments, suggestions, or
code to this patchset and related support patches: Chandler Carruth, Chih-Mao
Chen, David Chisnall, Simon Cook, David Craven, Hal Finkel, James Y Knight,
David Majnemer, Ed Maste, Krzysztof Parzyszek, Jordy Portman, Philip Reames,
Tim Northover, Eugene Zalenko, Florian Zeitz. Apologies to anybody who I've
missed.

This work has been performed through lowRISC CIC <http://www.lowrisc.org>, a
not-for-profit company. If your company would like to see my work on RISC-V
LLVM to be sustained or to accelerate, contributing sponsorship and/or
development time is the best way to do that. Please contact asb at lowrisc.org if
you would like to discuss sponsorship, or have questions about code
contributions that you can't discuss on-list.