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

[Hal Finkel via llvm-dev]

----- 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.

 -Hal

> 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