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. Note: a version of this message has also been sent to the llvm-dev mailing list < http://lists.llvm.org/pipermail/llvm-dev/2017-August/116709.html>;. ## 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, Dylan McKay, 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(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/groups.riscv.org/group/sw-dev/. To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH294u5V... .

Wow. Great work! Any chance on some information about what upstream version of LLVM to use and how to install it? I try running the patches and patch seems to just hang on me.

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)?

On 23 Aug 2017, at 7:26 AM, John Leidel <john.leidel(a)gmail.com&gt; wrote: 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? cheers john On Tue, Aug 22, 2017 at 3:42 AM, Alex Bradbury <asb(a)asbradbury.org&gt; 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. > > Note: a version of this message has also been sent to the llvm-dev > mailing list <http://lists.llvm.org/pipermail/llvm-dev/2017- > August/116709.html>. > > ## 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, Dylan McKay, 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(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/ > groups.riscv.org/group/sw-dev/. > To view this discussion on the web visit https://groups.google.com/a/ > groups.riscv.org/d/msgid/sw-dev/CA%2BwH294u5VtyHfryWcN5s0ku74j% > 2Br5N-MVJq8yHKG64AeqDcmw%40mail.gmail.com. >

>>>> On Tue, 22 Aug 2017 09:42:25 +0100, Alex Bradbury <asb(a)asbradbury.org&gt; said:

Sadly, the lack of review activity remains a major barrier to getting the patchset merged upstream.

On 6 Sep 2017, at 16:08, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: On 6 September 2017 at 16:02, David Chisnall <David.Chisnall(a)cl.cam.ac.uk&gt; wrote: > On 6 Sep 2017, at 15:21, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: >> >> Sadly, the lack of review activity remains a major barrier to getting >> the patchset merged upstream. > > Note that LLVM permits post-commit review at the discretion of the code owner. I’d suggest that you request permission to do this from the designated code owner for the RISC-V back end. He’s some guy called Alex Bradbury, maybe you know him? It's possible I misunderstood the review policy here, but I understood that it is considered inappropriate to switch to post-commit review after the code review process has been started. I agree, many future patches might be best off going in with post-commit review. This would be a shame, as when reviewers have waded in I've always had useful feedback which has improved code quality.

• Code can be reviewed either before it is committed or after. We expect major changes to be reviewed before being committed, but smaller changes (or changes where the developer owns the component) can be reviewed after commit.

On 6 September 2017 at 16:10, David Chisnall <David.Chisnall(a)cl.cam.ac.uk&gt; wrote: > >> On 6 Sep 2017, at 16:08, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: >> >> On 6 September 2017 at 16:02, David Chisnall >> <David.Chisnall(a)cl.cam.ac.uk&gt; wrote: >>> On 6 Sep 2017, at 15:21, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: >>>> >>>> Sadly, the lack of review activity remains a major barrier to getting >>>> the patchset merged upstream. >>> >>> Note that LLVM permits post-commit review at the discretion of the code owner. I’d suggest that you request permission to do this from the designated code owner for the RISC-V back end. He’s some guy called Alex Bradbury, maybe you know him? >> >> It's possible I misunderstood the review policy here, but I understood >> that it is considered inappropriate to switch to post-commit review >> after the code review process has been started. I agree, many future >> patches might be best off going in with post-commit review. This would >> be a shame, as when reviewers have waded in I've always had useful >> feedback which has improved code quality. > > The relevant part is: > >> • Code can be reviewed either before it is committed or after. We expect major changes to be reviewed before being committed, but smaller changes (or changes where the developer owns the component) can be reviewed after commit. > > Specifically, note the ‘or where the developer owns the component’ part. Sure, though I was put off by the subsequent "Specifically, once a patch is sent out for review, it needs an explicit “looks good” before it is submitted. Do not assume silent approval, or request active objections to the patch with a deadline." part. I'll pursue this issue on llvm-dev. Thanks, Alex -- 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/groups.riscv.org/group/sw-dev/. To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH296KCE....

I was actually going to make a slight change in approach for the llvm-integration repo, motivated by the desire from you (Andes) to work on top of an LLVM 5.0 base. There are advantages and disadvantages to this

On 19 September 2017 at 10:49, Shiva Chen <shiva0217(a)gmail.com&gt; wrote: > We plan to contribute our patchset to riscv-llvm-integration repo. > But it seems that the riscv-llvm-integration repo is not the latest > code base available in > https://github.com/lowRISC/riscv-llvm, where our porting started. > Is there any reason why they are different? If not, > would you mind updating riscv-llvm-integration repo ? I was actually going to make a slight change in approach for the llvm-integration repo, motivated by the desire from you (Andes) to work on top of an LLVM 5.0 base. There are advantages and disadvantages to this, but I'd really like to minimise the number of different trees we all have to contend with. Therefore I'm going to set up a riscv-llvm-integration branch based on 5.0 and make that the new default. I'll push it later today - it will take a little while to compile-test each commit and I've got a meeting soon which is going to take up some of my time. In the meantime, you should be able to work against a tree with the lowrisc/riscv-llvm patches applied, and your work can be trivially transplanted as soon as I push the new branch. Even though we hope this work on the compressed instruction set should be merged relatively quickly, I'd really recommend trying to keep your commit history clean and making use of git rebase as you develop - it will make it much easier to update the code if there are any other changes in lib/Target/RISCV.

I think we just have different concern, for Andes, we need a stable version for production and release to customer, so base on stable version is best choice for us, but we also intended to put resource on upstream.