On Tue, Dec 8, 2020 at 2:08 AM Jim Wilson <j...@sifive.com> 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.
Yes, using github seems like a bad choice here for this very reason. > 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. In the end it's up to target maintainers (on power we have/had -mfuture for example). But honestly I don't like exposing this kind of stuff to users and thus would prefer a branch for such stuff. But as said - it's up to the target maintainers. You could also paywall it behind a configure switch - as distributor I'd make sure to not enable "support" for -menable-experimental-extensions. Richard. > Jim
