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

Wed Aug 17 12:55:17 PDT 2016

Slightly off-topic, but if you want to port the entire toolchain to RISC-V,
you may want to add RISC-V support to LLD. I took a quick look at the
specification a few months ago and found that that's pretty straightforward
EFL ABI, so I expect you only need a few hundred lines of new code to
support RISC-V. I actually tried to do that at that moment as my weekend
project but gave up because I found that no code was upstreamed.

On Wed, Aug 17, 2016 at 2:14 AM, Alex Bradbury via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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. 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/e4173646/attachment.html>