[llvm-dev] [RFC] RISC-V backend

Sun May 28 09:35:42 PDT 2017

Hi,

I’m pretty interested in developing RISC-V backend. But the information across mailing list, upstream codebase and the riscv.org <http://riscv.org/> website is a little bit scattered and confused. Here are some facts I’ve known:

1. Colin has finished a great job on https://github.com/riscv/riscv-llvm <https://github.com/riscv/riscv-llvm>, the riscv-trunk branch is upstreaming with the trunk
2. There is also a clang frontend on https://github.com/riscv/riscv-clang <https://github.com/riscv/riscv-clang>. I guess the riscv-trunk branch is also upstreaming with the trunk
3. Alex had submitted some patches for code review. About 7 of them is not accepted yet
4. Currently the upstream codebase are mostly consist of MC part. Seems that it’s not able to be tested from llc

Please correct me if I’m wrong.

My question is:
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?
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.

Best Regards,
Bekket McClane
> Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> 於 2016年10月10日 上午5:41 寫道：
> 
> On 17 August 2016 at 10:14, Alex Bradbury <asb at asbradbury.org> wrote:
>> The current status is that I have submitted a series of 10 patches
>> implementing assembler support and an initial set of relocations and fixups.
>> Help reviewing these would be very welcome, do let me know if you'd like to be
>> CCed in or added as a reviewer to future patches. I'd ultimately like the
>> RISC-V backend to be considered a "reference" backend, and as such
>> I specifically welcome reviews you might worry are pedantic.
>> 
>> Please find the current set of patches for your review here:
>> * <https://reviews.llvm.org/differential/?authors=asb>
> 
> Hi all, I wanted to share an update on the current status of things.
> 
> * https://reviews.llvm.org/D23557 1/10. RISC-V triple parsing code.
> Reviewed and ready to land
> * https://reviews.llvm.org/D23558 2/10. RISC-V ELF defines. Reviewed
> and ready to land
> * https://reviews.llvm.org/D23560 3/10. Stub RISC-V backend. Reviewed
> and ready to land
> * https://reviews.llvm.org/D23561 4/10. Add basic .td files. Reviewed,
> but really needs another look from reviewers due to a revised patch
> * https://reviews.llvm.org/D23496 Move OperandMatchResultTy to
> MCTargetAsmParser. Unreviewed.
> * https://reviews.llvm.org/D23562. 5/10. Add bare-bones RISC-V
> MCTargetDesc. Reviewed and ready to land.
> * https://reviews.llvm.org/D23563 6/10. Add basic RISCVAsmParser.
> Review comments addressed, needs acceptance.
> * https://reviews.llvm.org/D23564 7/10. Add RISCVInstPrinter and basic
> tests. Reviewed and ready to land.
> * https://reviews.llvm.org/D23566 8/10. Add support for all RV32I
> instructions. Review comments addressed, needs acceptance
> * https://reviews.llvm.org/D23567 9/10. Add support for disassembly.
> Reviewed and ready to land.
> * https://reviews.llvm.org/D23568 10/10. Add fixups and relocations
> necessary for %hi, %lo and friends. Awaiting review
> 
> So 6 are reviewed and ready to land, 3 have started the review process
> and awaiting signoff, and 2 remain unreviewed. Many thanks to everyone
> who has chipped in with review comments, the patches have improved
> significantly as a result.
> 
> If you would like to help, but poring through backend code doesn't
> appeal to you, it would be really great to:
> 1) Review this minor patch that moves the definition of
> OperandMatchResultTy to a header rather than in tblgenned code
> 2) Check out the discussion about variable-sized register classes. It
> raises lots of interesting questions, and an improvement to LLVM here
> could benefit multiple backends, including RISC-V
> <http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html>.
> I'm not blocked on this, but would prefer to use something like this
> proposal to avoid having to define every instruction twice (once for
> RV32, again for RV64).
> 
> I'm really pleased that I'll be able to make it over to the US LLVM
> Developers' Meeting in November. The BoF submission Colin and I put in
> sadly wasn't accepted, but perhaps a few people may be interested in
> having the sort of discussion we proposed in a more informal setting
> (i.e. the 'corridor track' - just say hi!):
> 
> * The open nature of RISC-V gives a unique opportunity to contribute
> to its development. How can we, as compiler engineers best contribute
> our expertise to this effort?
> * How can we rapidly achieve first-class RISC-V support across LLVM projects?
> * What can we do to make LLVM more accessible to groups performing
> computer architecture research using RISC-V?
> * Are there lessons to be learned from the history of other
> architectures in LLVM, mistakes that we can avoid?
> * What can we do to track improvements (or regressions) in performance
> and code size over time?
> * Are there areas where the RISC-V community can contribute to the
> general LLVM infrastructure? e.g. moving target-specific passes to the
> middle-end.
> * There is a potential for a large diversity in RISC-V implementations
> with support for different instruction set subsets or new custom
> instructions. How can LLVM deal with this?
> 
> Best,
> 
> Alex
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170529/61933edb/attachment.html>