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

[Philip Reames via llvm-dev]

On 08/17/2016 09:00 AM, Mehdi Amini via llvm-dev wrote:
>
>> On Aug 17, 2016, at 8:49 AM, Hal Finkel via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> ----- Original Message -----
>>> From: "Alex Bradbury via llvm-dev" <llvm-dev at lists.llvm.org 
>>> <mailto:llvm-dev at lists.llvm.org>>
>>> To: "llvm-dev" <llvm-dev at lists.llvm.org 
>>> <mailto: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!
>
+1 from me too.  That may have been obvious from my reviews, but figured 
it didn't hurt to say explicitly.  :)
>>
>>
>>> 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 <mailto: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
>
>
>
> _______________________________________________
> 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/20160826/042b988f/attachment-0001.html>