public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* RISC-V -menable-experimental-extensions option
@ 2020-12-08  1:06 Jim Wilson
  2020-12-08  7:57 ` Richard Biener
  2020-12-09  0:22 ` Jeff Law
  0 siblings, 2 replies; 3+ messages in thread
From: Jim Wilson @ 2020-12-08  1:06 UTC (permalink / raw)
  To: Binutils, GCC Development

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.

Jim

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RISC-V -menable-experimental-extensions option
  2020-12-08  1:06 RISC-V -menable-experimental-extensions option Jim Wilson
@ 2020-12-08  7:57 ` Richard Biener
  2020-12-09  0:22 ` Jeff Law
  1 sibling, 0 replies; 3+ messages in thread
From: Richard Biener @ 2020-12-08  7:57 UTC (permalink / raw)
  To: Jim Wilson; +Cc: Binutils, GCC Development

On Tue, Dec 8, 2020 at 2:08 AM Jim Wilson <jimw@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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RISC-V -menable-experimental-extensions option
  2020-12-08  1:06 RISC-V -menable-experimental-extensions option Jim Wilson
  2020-12-08  7:57 ` Richard Biener
@ 2020-12-09  0:22 ` Jeff Law
  1 sibling, 0 replies; 3+ messages in thread
From: Jeff Law @ 2020-12-09  0:22 UTC (permalink / raw)
  To: Jim Wilson, Binutils, GCC Development



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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-12-09  0:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-08  1:06 RISC-V -menable-experimental-extensions option Jim Wilson
2020-12-08  7:57 ` Richard Biener
2020-12-09  0:22 ` Jeff Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).