<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">I’m pretty interested in developing RISC-V backend. But the information across mailing list, upstream codebase and the <a href="http://riscv.org" class="">riscv.org</a> website is a little bit scattered and confused. Here are some facts I’ve known:</div><div class=""><br class=""></div><div class="">1. Colin has finished a great job on <a href="https://github.com/riscv/riscv-llvm" class="">https://github.com/riscv/riscv-llvm</a>, the riscv-trunk branch is upstreaming with the trunk</div><div class="">2. There is also a clang frontend on <a href="https://github.com/riscv/riscv-clang" class="">https://github.com/riscv/riscv-clang</a>. I guess the riscv-trunk branch is also upstreaming with the trunk</div><div class="">3. Alex had submitted some patches for code review. About 7 of them is not accepted yet</div><div class="">4. Currently the upstream codebase are mostly consist of MC part. Seems that it’s not able to be tested from llc</div><div class=""><br class=""></div><div class="">Please correct me if I’m wrong.</div><div class=""><br class=""></div><div class="">My question is:</div><div class="">1. Probably the biggest one: What’s next step? I’m neither the expert of RISCV nor good at backend development so I’m afraid I can’t review the patches. But I’m willing to develop the ISel and scheduling part. Is helping to port the work from Colin’s github repo to upstream codebase a good starting point?</div><div class="">2. What’s the clang’s status? I know it’s a little bit weird to ask in this mailing list but Colin’s work on github seems to be paused and there is no patches submitted to the code review, I just want to know whether helping to port the work from github to upstream would also be a good idea.</div><div class=""><br class=""></div><div class="">Best Regards,</div><div class="">Bekket McClane</div><div class=""><div><blockquote type="cite" class=""><div class="">Alex Bradbury via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> 於 2016年10月10日 上午5:41 寫道：</div><br class="Apple-interchange-newline"><div class=""><div class="">On 17 August 2016 at 10:14, Alex Bradbury <<a href="mailto:asb@asbradbury.org" class="">asb@asbradbury.org</a>> wrote:<br class=""><blockquote type="cite" class="">The current status is that I have submitted a series of 10 patches<br class="">implementing assembler support and an initial set of relocations and fixups.<br class="">Help reviewing these would be very welcome, do let me know if you'd like to be<br class="">CCed in or added as a reviewer to future patches. I'd ultimately like the<br class="">RISC-V backend to be considered a "reference" backend, and as such<br class="">I specifically welcome reviews you might worry are pedantic.<br class=""><br class="">Please find the current set of patches for your review here:<br class="">* <<a href="https://reviews.llvm.org/differential/?authors=asb" class="">https://reviews.llvm.org/differential/?authors=asb</a>><br class=""></blockquote><br class="">Hi all, I wanted to share an update on the current status of things.<br class=""><br class="">* <a href="https://reviews.llvm.org/D23557" class="">https://reviews.llvm.org/D23557</a> 1/10. RISC-V triple parsing code.<br class="">Reviewed and ready to land<br class="">* <a href="https://reviews.llvm.org/D23558" class="">https://reviews.llvm.org/D23558</a> 2/10. RISC-V ELF defines. Reviewed<br class="">and ready to land<br class="">* <a href="https://reviews.llvm.org/D23560" class="">https://reviews.llvm.org/D23560</a> 3/10. Stub RISC-V backend. Reviewed<br class="">and ready to land<br class="">* <a href="https://reviews.llvm.org/D23561" class="">https://reviews.llvm.org/D23561</a> 4/10. Add basic .td files. Reviewed,<br class="">but really needs another look from reviewers due to a revised patch<br class="">* <a href="https://reviews.llvm.org/D23496" class="">https://reviews.llvm.org/D23496</a> Move OperandMatchResultTy to<br class="">MCTargetAsmParser. Unreviewed.<br class="">* <a href="https://reviews.llvm.org/D23562" class="">https://reviews.llvm.org/D23562</a>. 5/10. Add bare-bones RISC-V<br class="">MCTargetDesc. Reviewed and ready to land.<br class="">* <a href="https://reviews.llvm.org/D23563" class="">https://reviews.llvm.org/D23563</a> 6/10. Add basic RISCVAsmParser.<br class="">Review comments addressed, needs acceptance.<br class="">* <a href="https://reviews.llvm.org/D23564" class="">https://reviews.llvm.org/D23564</a> 7/10. Add RISCVInstPrinter and basic<br class="">tests. Reviewed and ready to land.<br class="">* <a href="https://reviews.llvm.org/D23566" class="">https://reviews.llvm.org/D23566</a> 8/10. Add support for all RV32I<br class="">instructions. Review comments addressed, needs acceptance<br class="">* <a href="https://reviews.llvm.org/D23567" class="">https://reviews.llvm.org/D23567</a> 9/10. Add support for disassembly.<br class="">Reviewed and ready to land.<br class="">* <a href="https://reviews.llvm.org/D23568" class="">https://reviews.llvm.org/D23568</a> 10/10. Add fixups and relocations<br class="">necessary for %hi, %lo and friends. Awaiting review<br class=""><br class="">So 6 are reviewed and ready to land, 3 have started the review process<br class="">and awaiting signoff, and 2 remain unreviewed. Many thanks to everyone<br class="">who has chipped in with review comments, the patches have improved<br class="">significantly as a result.<br class=""><br class="">If you would like to help, but poring through backend code doesn't<br class="">appeal to you, it would be really great to:<br class="">1) Review this minor patch that moves the definition of<br class="">OperandMatchResultTy to a header rather than in tblgenned code<br class="">2) Check out the discussion about variable-sized register classes. It<br class="">raises lots of interesting questions, and an improvement to LLVM here<br class="">could benefit multiple backends, including RISC-V<br class=""><<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html</a>>.<br class="">I'm not blocked on this, but would prefer to use something like this<br class="">proposal to avoid having to define every instruction twice (once for<br class="">RV32, again for RV64).<br class=""><br class="">I'm really pleased that I'll be able to make it over to the US LLVM<br class="">Developers' Meeting in November. The BoF submission Colin and I put in<br class="">sadly wasn't accepted, but perhaps a few people may be interested in<br class="">having the sort of discussion we proposed in a more informal setting<br class="">(i.e. the 'corridor track' - just say hi!):<br class=""><br class="">* The open nature of RISC-V gives a unique opportunity to contribute<br class="">to its development. How can we, as compiler engineers best contribute<br class="">our expertise to this effort?<br class="">* How can we rapidly achieve first-class RISC-V support across LLVM projects?<br class="">* What can we do to make LLVM more accessible to groups performing<br class="">computer architecture research using RISC-V?<br class="">* Are there lessons to be learned from the history of other<br class="">architectures in LLVM, mistakes that we can avoid?<br class="">* What can we do to track improvements (or regressions) in performance<br class="">and code size over time?<br class="">* Are there areas where the RISC-V community can contribute to the<br class="">general LLVM infrastructure? e.g. moving target-specific passes to the<br class="">middle-end.<br class="">* There is a potential for a large diversity in RISC-V implementations<br class="">with support for different instruction set subsets or new custom<br class="">instructions. How can LLVM deal with this?<br class=""><br class="">Best,<br class=""><br class="">Alex<br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>