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

[James Y Knight via llvm-dev]

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

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

This sounds like a great plan. The only concern I have is that the process
actually finish, and not end up in a limbo state for a year.

I haven't actually been following the story of the AVR backend at all, but
afaik the current status is that there's a partially completed AVR backend
in trunk that's been under construction for a year or so, and a functional
backend in another repository, which people actually use. However that
situation came to pass, it seems a very unfortunate state to be in, and it
would be sad if this rewrite of the RISC-V backend ended up with the
upstream repository having the same mostly-unusable status for RISC-V.

Note, I want to stress I am __not__ disagreeing with your proposed plan! I
just want to mention that concern.

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

Yes, it would probably make a lot of sense to transition
the WritingAnLLVMBackend document from describing the SPARC backend to the
RISC-V backend, at some future point.


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

I would suggest starting CodeGen before getting too far into MC, since a
lot of things about the instruction definitions are only for codegen, it's
easy to make something that works for MC but isn't structured right for
codegen. That is to say, I'd recommend starting codegen after doing MC
through RV32G+RV64G at *most*, rather than at *least*, and it might even
make sense to start on CodeGen support after only RV32I/RV64I.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/d01abd1a/attachment.html>