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.
On Mon, Aug 21, 2017, at 12:06, Alex Bradbury via llvm-dev 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 > <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.Hey Alex, thanks for the status update and congratulations to all your good work. I am really looking forward to follow the upstreaming process over the last weeks. Best, Tobias> > ## 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. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 21 August 2017 at 11:06, Alex Bradbury <asb at asbradbury.org> wrote:> ## 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.I've gone ahead and separated instruction and pattern definitions, refreshing the affected patches. Since starting this thread, I'm able to add Dylan McKay to my credits list - thanks for stepping in with useful review comments. I'd still really, really appreciate additional help in terms of moving the review process forwards. I've put a lot of effort in to splitting this whole thing up in to incremental and testable patches (to the extent this is feasible for a new backend at least) in order to make reviewing as easy as possible. Best, Alex
On 23 Aug 2017, at 22:54, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > I've gone ahead and separated instruction and pattern definitions, > refreshing the affected patches.Thanks. The RISC-V back end is really starting to look like a good example back end. David
On 21 August 2017 at 11:06, Alex Bradbury <asb at 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 > <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 continuing to do all that I can get the patchset reviewed for upstream merging, but given review activity seems to have slowed to a halt again I've gone ahead and set up a repository for downstream collaboration, to accept pull requests from others etc. See the README at <https://github.com/lowRISC/riscv-llvm-integration> for more information. The intent is that this is a temporary measure, to allow productive collaboration while upstream RISC-V support remains blocked on lack of reviewers. Best, Alex