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

[Alex Bradbury via llvm-dev]

On 17 August 2016 at 17:33, James Y Knight <jyknight at google.com> wrote:
> 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.

That's a fair concern. I think the upstreaming of AVR has been slower
than hoped because
1) as I understand it, it's a spare time project for everyone involved
2) Dylan has found it difficult to get code reviewers - it remains to
be seen how problematic that will be for RISC-V, but there's certainly
a lot of RISC-V interest
3) AVR is I think in general a more difficult target

lowRISC CIC (the UK not-for-profit we set up to support the lowRISC
efforts) is now becoming my full time focus, and as part of that the
majority of my time will, for some time, be on RISC-V LLVM. To move
faster, we of course welcome additional support in the form of either
engineering time or sponsorship from any parties interested in open
source hardware, the RISC-V ecosystem, or LLVM+RISC-V more
specifically.

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

That's a really good point. I was hoping to have completed some
CodeGen to have fully proven the MC-first approach before submitting,
but getting everything lined up to move to lowRISC full-time took more
time than I anticipated. I think the milestone I really want to hit is
where I can easily cross-validate against gcc - i.e. assembling its .s
output. I think we're actually almost at the point where I can do
that, and I agree there's a lot of value in getting the CodeGen
support well underway. Not least, once there's a reasonable CodeGen
and MC baseline I think it will be somewhat easier for more people to
work in parallel on additional features and optimisations. I'll aim to
move to CodeGen ASAP.

Thanks,

Alex