Yes. It’s pretty neat. I remember spending a few days looking at the LLVM code base and
realising it would be no small commitment to get up-to-speed and productive. It is a
relatively daunting task to familiarise oneself with the LLVM codebase, in addition to
this port essentially being started from a clean slate. Hopefully I can help when the port
is further along.
On 23 Aug 2017, at 7:26 AM, John Leidel <john.leidel(a)gmail.com>
Alex, as always, this is awesome work. I perused through your outstanding
issue list and I believe there are definitely places whereby the community
can help contribute at this stage in the development. Regarding community
involvement, how would you like to proceed? Would you prefer to funnel the
patches through lowRISC such that we maintain continuity in the upstream
patch process (at least until this is fully merged into the upstream
tree)? David Chisnall, thoughts?
On Tue, Aug 22, 2017 at 3:42 AM, Alex Bradbury <asb(a)asbradbury.org> wrote:
> 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
> provides a good overview of my approach. Thanks to funding from a third
> I've recently been able to return to this effort as my main focus. Now
> like a good time to give an update on where the RISCV backend is at, and
> you can help.
> Note: a version of this message has also been sent to the llvm-dev
> mailing list <http://lists.llvm.org/pipermail/llvm-dev/2017-
> ## Current status
> * A full, regularly rebased patchset can be found here
> * 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>
> 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
> easy for further development work to be parallelised, and for others to
> 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
> incredibly valuable way to do so. If you would like to be listed as a
> 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
> 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
;, 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
> parties who have expressed an interest.
> ## Credits and support
> Thank you to everyone who has contributed review comments, suggestions, or
> to this patchset and related support patches: Chandler Carruth, Chih-Mao
> David Chisnall, Simon Cook, David Craven, Hal Finkel, James Y Knight, David
> Majnemer, Ed Maste, Dylan McKay, Krzysztof Parzyszek, Jordy Portman, Philip
> Reames, Tim Northover, Eugene Zalenko, Florian Zeitz. Apologies to anybody
> I've missed.
> This work has been performed through lowRISC CIC <http://www.lowrisc.org>
> 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(a)lowrisc.org if
> you would like to discuss sponsorship, or have questions about code
> contributions that you can't discuss on-list.
> You received this message because you are subscribed to the Google Groups
> "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sw-dev+unsubscribe(a)groups.riscv.org.
> To post to this group, send email to sw-dev(a)groups.riscv.org.
> Visit this group at https://groups.google.com/a/
> To view this discussion on the web visit https://groups.google.com/a/