<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 17, 2016 at 2:14 AM, Alex Bradbury via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I am proposing the integration of a backend targeting the RISC-V ISA.<br>
<br>
RISC-V is a free and open instruction set architecture that was originally<br>
developed at UC Berkeley. Future development of the ISA specification will be<br>
handled by the 501(c)(6) non-profit RISC-V Foundation and its members<br>
<<a href="https://riscv.org/membership/?action=viewlistings" rel="noreferrer" target="_blank">https://riscv.org/membership/<wbr>?action=viewlistings</a>>. You can find much more<br>
information at the RISC-V website <<a href="https://riscv.org/" rel="noreferrer" target="_blank">https://riscv.org/</a>>, including the current<br>
ISA specification <<a href="https://riscv.org/specifications/" rel="noreferrer" target="_blank">https://riscv.org/<wbr>specifications/</a>>. You might note that<br>
RISC-V defines 32-bit and 64-bit variants and also supports a compressed<br>
variant, allowing 16-bit instructions to be freely intermingled with the<br>
standard 32-bit representations. The standard is structured to allow<br>
implementers to choose appropriate subsets to support, for instance a<br>
micro-controller might support 'RV32I' (32-bit RISC-V with the integer<br>
instructions) and an application core running Linux might implement RV64IMAFD<br>
(commonly shortened to RV64G: 64-bit with integer instructions, the multiply<br>
extension, atomics, and single and double precision floating point). A<br>
generous portion of the opcode space is left reserved for implementers or<br>
researchers to add their own instructions.<br>
<br>
In line with the proposed policy for adding a new target<br>
(<a href="https://reviews.llvm.org/D23162" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D23162</a>), RISC-V has a clear specification, multiple<br>
software models, and multiple FPGA implementations as well as prototype ASICs<br>
from various groups. At lowRISC (<a href="http://www.lowrisc.org/" rel="noreferrer" target="_blank">http://www.lowrisc.org/</a>), inspired by our<br>
previous experience with the Raspberry Pi project, we are working towards<br>
creating a completely open source RISC-V SoC and producing low-cost<br>
development boards around it. Feel free to contact me off-list to discuss<br>
lowRISC further. LLVM is a key part of our development plan, and with<br>
community approval I would like to act as maintainer for the backend. The vast<br>
majority of my LLVM work over the past 6 years has sadly been out-of-tree, but<br>
I'm far from new to the project.<br>
<br>
In the RISC-V community right now, GCC is by some way the more stable compiler<br>
port. We've discussed best way of moving forward with LLVM at the last couple<br>
of RISC-V Workshops and a number of us concluded a fresh codebase may be the<br>
best way to move forwards. Producing a series of patches that introduce RISC-V<br>
support incrementally in easy-to-review chunks with associated test cases at<br>
every point also allows us to get the maximum benefit from LLVM's code review<br>
procedure. It also provides a good basis for more detailed documentation on<br>
writing an LLVM backend (and making modifications to an existing one, e.g.<br>
making it much easier for a research group wanting to explore RISC-V changes).<br>
This is an area I also hope to contribute to. The approach of small,<br>
incremental patches is somewhat similar to what is being done with the AVR<br>
backend. I'm grateful to David Chisnall who suggested that starting with the<br>
MC layer may be a productive way to go about developing this backend, and so<br>
far this seems to be working well.<br>
<br>
The current status is that I have submitted a series of 10 patches<br>
implementing assembler support and an initial set of relocations and fixups.<br>
Help reviewing these would be very welcome, do let me know if you'd like to be<br>
CCed in or added as a reviewer to future patches. I'd ultimately like the<br>
RISC-V backend to be considered a "reference" backend, and as such<br>
I specifically welcome reviews you might worry are pedantic.<br>
<br>
Please find the current set of patches for your review here:<br>
* <<a href="https://reviews.llvm.org/differential/?authors=asb" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>differential/?authors=asb</a>><br>
<br>
I've obviously spent a lot of time with the MC layer recently, and I'd be<br>
happy to put that to use in helping review MC patches for other archs.<br>
<br>
Mini development roadmap:<br>
* Complete MC layer (supporting up to RV32+RV64G at least)<br>
  * There is currently no specification for supported RISC-V assembly syntax,<br>
  mnemonics etc. The ideal solution may not always be "whatever the GCC port<br>
  currently does", so some aspect of this will involve discussions with the<br>
  wider RISC-V software community.<br>
* Codegen<br>
* Compressed instruction set support (RVC)<br>
* Benchmarking and comparison to GCC RISC-V (and potentially other archs)<br>
<br>
Finally I'd like to give a prominent mention to Colin Schmidt, the UC Berkeley<br>
student who has been maintaining the current out-of-tree RISC-V LLVM port<br>
<<a href="https://github.com/riscv/riscv-llvm" rel="noreferrer" target="_blank">https://github.com/riscv/<wbr>riscv-llvm</a>>. The RISC-V community owes him a debt of<br>
gratitude.<br>
<br>
All comments very welcome,<br>
<br>
Alex<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>