On 12/7/20 6:06 PM, Jim Wilson wrote:
> I'm not aware of any other target that has a similar feature, so I thought
> a bit of discussion first might be useful.
>
> For most ISAs, there is one organization that owns it, and does development
> internally, in private.  For RISC-V, the ISA is owned by RISC-V
> International which has no developers.  The development all happens
> externally, in public, spread across at least a dozen different
> organizations.  So we have the problem of coordinating this work,
> especially for draft versions of extensions.  So we would like to add
> support for draft extensions to mainline, controlled by a
> -menable-experimental-extensions option.  For features enabled by this
> option, there would be no guarantee that the next compiler release is
> compatible with the previous one, since the draft extension may change in
> incompatible ways.
>
> LLVM already has support for this option.
>     http://lists.llvm.org/pipermail/llvm-dev/2020-January/138364.html
>     https://reviews.llvm.org/D73891
>
> We are still discussing the details of how this will work.  We may want to
> limit this to 'stable" draft extensions, and put the unstable drafts on a
> vendor branch.
>
> We have been doing work on branches in the github.com riscv tree, but there
> are issues with tracking who has copyright assignments, issues with
> identifying who exactly a github user actually is, and issues with getting
> the right set of people right access to the trees.  These won't be problems
> if we are using the FSF trees instead.
>
> We want this draft extension support on mainline for the same reasons that
> the LLVM developers do, to ensure that everyone is working in the same
> branch in the upstream tree.  And it is easiest to do that if that branch
> is mainline.
>
> This is just a binutils and gcc proposal at the moment, but we might need
> something on the gdb side later, like a
>   set riscv experimental-extensions 1
> or whatever command to enable support for draft extensions.
It seems reasonable to me.  The worst thing that happens is you find
it's not terribly better than what we're currently doing and we scramble
the process again to work better.

jeff

Reply via email to