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

[Michael Clark via llvm-dev]

Hi Bekket,

P.S. Apologies if this is not threading, as I’m replying to the digest.

> On 29 May 2017, at 7:00 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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/><http://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> <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> <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

Yes. You might want to read this thread on the RISC-V mailing list while I was discovering the state of upstream LLVM, Colin’s port and Alex’s patchset:

- https://groups.google.com/a/groups.riscv.org/forum/#!msg/sw-dev/z1HZdVcRwVw/PUGiZEJ8BAAJ <https://groups.google.com/a/groups.riscv.org/forum/#!msg/sw-dev/z1HZdVcRwVw/PUGiZEJ8BAAJ>

Colin’s port is against a very old version of LLVM nevertheless it is a substantial body of work. I couldn’t get codegen in Clang to work however it may work with -O0. It obviously takes a lot of effort to track upstream, when the arch is not yet integrated into mainline. Alex’s port is the most up-to-date and I have experimented with Alex’s MC layer tests using llvm-lit. Alex has some follow ups to the RISC-V mailing list on the calling convention with a python tool that is a reference implementation for the calling convention. The calling convention work is required for Clang enablement. I’m not sure if the patches have landed upstream.

Here is the public repo with current patchset which should be applied on top of LLVM upstream (this was the case a 3 months back):

- https://github.com/lowrisc/riscv-llvm <https://github.com/lowrisc/riscv-llvm>

Alex mentioned some infrastructure dependencies for an architecture that supports both 32-bit and 64-bit registers while sharing the same tablegen machine instruction definitions. MIPS currently duplicates tablegen definitions and is not a “reference architecture”. The idea is that RISC-V could become a “reference architecture” in LLVM so one would not duplicate the tablegen definitions for RV64 given most of the ISA definition is shared with RV32. I’m not sure if this capability is in mainline yet. You could look at Colin’s port for Clang enablement however the calling convention has changed and firmed up since the timeframe of Colin’s port.

LLVM has a relatively steep learning curve so I only got so far with my own investigation. I feel I could make progress if I had more time as I am slowly learning bits and pieces about LLVM internals but it would require sustained study of the codebase for a sustained amount of time to become productive.

Regards,
Michael.

> 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 <mailto:llvm-dev at lists.llvm.org>> 於 2016年10月10日 上午5:41 寫道：
>> 
>> On 17 August 2016 at 10:14, Alex Bradbury <asb at asbradbury.org <mailto: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 <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 <https://reviews.llvm.org/D23557> 1/10. RISC-V triple parsing code.
>> Reviewed and ready to land
>> * https://reviews.llvm.org/D23558 <https://reviews.llvm.org/D23558> 2/10. RISC-V ELF defines. Reviewed
>> and ready to land
>> * https://reviews.llvm.org/D23560 <https://reviews.llvm.org/D23560> 3/10. Stub RISC-V backend. Reviewed
>> and ready to land
>> * https://reviews.llvm.org/D23561 <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 <https://reviews.llvm.org/D23496> Move OperandMatchResultTy to
>> MCTargetAsmParser. Unreviewed.
>> * https://reviews.llvm.org/D23562 <https://reviews.llvm.org/D23562>. 5/10. Add bare-bones RISC-V
>> MCTargetDesc. Reviewed and ready to land.
>> * https://reviews.llvm.org/D23563 <https://reviews.llvm.org/D23563> 6/10. Add basic RISCVAsmParser.
>> Review comments addressed, needs acceptance.
>> * https://reviews.llvm.org/D23564 <https://reviews.llvm.org/D23564> 7/10. Add RISCVInstPrinter and basic
>> tests. Reviewed and ready to land.
>> * https://reviews.llvm.org/D23566 <https://reviews.llvm.org/D23566> 8/10. Add support for all RV32I
>> instructions. Review comments addressed, needs acceptance
>> * https://reviews.llvm.org/D23567 <https://reviews.llvm.org/D23567> 9/10. Add support for disassembly.
>> Reviewed and ready to land.
>> * https://reviews.llvm.org/D23568 <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 <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

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