<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 17, 2016 at 5: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Note, I want to stress I am __not__ disagreeing with your proposed plan! I just want to mention that concern.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Mini development roadmap:<br>
* Complete MC layer (supporting up to RV32+RV64G at least) </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">  * 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></blockquote><div><br></div><div>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.</div><div><br></div></div></div></div>