[lowrisc-dev] Re: [sw-dev] RISC-V LLVM status update

Alex Bradbury asb at asbradbury.org
Tue Sep 19 12:07:27 BST 2017

On 19 September 2017 at 11:54, David Chisnall
<David.Chisnall at cl.cam.ac.uk> wrote:
> On 19 Sep 2017, at 11:43, Alex Bradbury <asb at asbradbury.org> wrote:
>> I was actually going to make a slight change in approach for the
>> llvm-integration repo, motivated by the desire from you (Andes) to
>> work on top of an LLVM 5.0 base. There are advantages and
>> disadvantages to this
> Having tried both approaches, I’d say that the disadvantages massively outweigh the advantages.  There’s usually a lot of churn in the back-end APIs in LLVM (and as GlobalISel becomes the default, this is not going to slow down any time soon).  Trying to upgrade an entire release at once is a lot of effort and a lot more effort than doing regular merges from upstream.  Worse, you don’t catch regressions in other parts of the system that only affect your back end until a release is out, at which point it’s hard to find the exact commit that broke things for you and it’s no longer fresh in the mind of the person that wrote it.

I do agree with that, but I think the situation is little different vs
a typical out-of-tree backend here. The goal is to bridge the gap
between now and the code being merged upstream. The hope is that the
5.0 tree can effectively be discarded by the time 6.0 is branched. I'm
already committed to maintaining a continuously rebased patchset on
the latest LLVM master (github.com/lowrisc/riscv-llvm) of course. I'm
trying to strike a balance here by having 'just' the following three
* Upstream LLVM
* Continuously rebased patch queue
* Patches applied on 5.0

Rather than four cases:
* Upstream LLVM
* Continuously rebased patch queue
* Patches applied on 5.0
* Patches applied on upstream, never rebased

I too prefer merging in upstream changes regularly, but it's difficult
to fight the perception that this would be more "unstable" vs
something based on 5.0.



More information about the lowrisc-dev mailing list