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

Wed Aug 17 09:00:11 PDT 2016

> On Aug 17, 2016, at 8:49 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> ----- Original Message -----
>> From: "Alex Bradbury via llvm-dev" <llvm-dev at lists.llvm.org>
>> To: "llvm-dev" <llvm-dev at lists.llvm.org>
>> Sent: Wednesday, August 17, 2016 4:14:38 AM
>> Subject: [llvm-dev] [RFC] RISC-V backend
>> 
>> Hi all,
>> 
>> I am proposing the integration of a backend targeting the RISC-V ISA.
>> 
>> RISC-V is a free and open instruction set architecture that was
>> originally
>> developed at UC Berkeley. Future development of the ISA specification
>> will be
>> handled by the 501(c)(6) non-profit RISC-V Foundation and its members
>> <https://riscv.org/membership/?action=viewlistings>. You can find
>> much more
>> information at the RISC-V website <https://riscv.org/>, including the
>> current
>> ISA specification <https://riscv.org/specifications/>. You might note
>> that
>> RISC-V defines 32-bit and 64-bit variants and also supports a
>> compressed
>> variant, allowing 16-bit instructions to be freely intermingled with
>> the
>> standard 32-bit representations. The standard is structured to allow
>> implementers to choose appropriate subsets to support, for instance a
>> micro-controller might support 'RV32I' (32-bit RISC-V with the
>> integer
>> instructions) and an application core running Linux might implement
>> RV64IMAFD
>> (commonly shortened to RV64G: 64-bit with integer instructions, the
>> multiply
>> extension, atomics, and single and double precision floating point).
>> A
>> generous portion of the opcode space is left reserved for
>> implementers or
>> researchers to add their own instructions.
>> 
>> In line with the proposed policy for adding a new target
>> (https://reviews.llvm.org/D23162), RISC-V has a clear specification,
>> multiple
>> software models, and multiple FPGA implementations as well as
>> prototype ASICs
>> from various groups. At lowRISC (http://www.lowrisc.org/), inspired
>> by our
>> previous experience with the Raspberry Pi project, we are working
>> towards
>> creating a completely open source RISC-V SoC and producing low-cost
>> development boards around it. Feel free to contact me off-list to
>> discuss
>> lowRISC further. LLVM is a key part of our development plan, and with
>> community approval I would like to act as maintainer for the backend.
>> The vast
>> majority of my LLVM work over the past 6 years has sadly been
>> out-of-tree, but
>> I'm far from new to the project.
>> 
>> In the RISC-V community right now, GCC is by some way the more stable
>> compiler
>> port. We've discussed best way of moving forward with LLVM at the
>> last couple
>> of RISC-V Workshops and a number of us concluded a fresh codebase may
>> be the
>> best way to move forwards. Producing a series of patches that
>> introduce RISC-V
>> support incrementally in easy-to-review chunks with associated test
>> cases at
>> every point also allows us to get the maximum benefit from LLVM's
>> code review
>> procedure.
> 
> Yes, this is exactly the process we should follow when practical. I'm in favor of this effort.

+1

Thanks Alex!

— 
Mehdi

> 
> 
>> It also provides a good basis for more detailed
>> documentation on
>> writing an LLVM backend (and making modifications to an existing one,
>> e.g.
>> making it much easier for a research group wanting to explore RISC-V
>> changes).
>> This is an area I also hope to contribute to. The approach of small,
>> incremental patches is somewhat similar to what is being done with
>> the AVR
>> backend. I'm grateful to David Chisnall who suggested that starting
>> with the
>> MC layer may be a productive way to go about developing this backend,
>> and so
>> far this seems to be working well.
>> 
>> 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>
>> 
>> I've obviously spent a lot of time with the MC layer recently, and
>> I'd be
>> happy to put that to use in helping review MC patches for other
>> archs.
>> 
>> Mini development roadmap:
>> * Complete MC layer (supporting up to RV32+RV64G at least)
>>  * There is currently no specification for supported RISC-V assembly
>>  syntax,
>>  mnemonics etc. The ideal solution may not always be "whatever the
>>  GCC port
>>  currently does", so some aspect of this will involve discussions
>>  with the
>>  wider RISC-V software community.
>> * Codegen
>> * Compressed instruction set support (RVC)
>> * Benchmarking and comparison to GCC RISC-V (and potentially other
>> archs)
>> 
>> Finally I'd like to give a prominent mention to Colin Schmidt, the UC
>> Berkeley
>> student who has been maintaining the current out-of-tree RISC-V LLVM
>> port
>> <https://github.com/riscv/riscv-llvm>. The RISC-V community owes him
>> a debt of
>> gratitude.
>> 
>> All comments very welcome,
>> 
>> Alex
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20160817/e64ad657/attachment.html>