[committed] RISC-V: XVentanaCondops support

  This patch adds support for the Veyron V1's XVentanaCondOps extension. 
These instructions provide a primitive that corresponds to:

x = (a eq/ne 0) ? x : 0;

Ie, it's a conditional zero.  On top of this primitive the compiler can 
build a variety of branchless sequences to implement conditional 
arithmetic, logical and select operations.

If you follow the RISC-V world, you'll realize XVentanaCondops is 
essentially the same as the Zicond extension that is currently going 
through the ratification process.  The only material difference is the 
instruction encoding.

The Veyron V1 processor implements XVentanaCondOps, but not Zicond. 
That's simply due to timing.

This work was done by Philipp Tomsich and the VRULL team for Ventana. 
Going forward I'm the best point of contact for this code.

Reviewed, tested and pushed to the trunk.

Jeff
commit 1656d3f8ef56a16745689c03269412988ebcaa54
Author: Philipp Tomsich <philipp.tomsich@vrull.eu>
Date:   Wed Apr 26 14:09:34 2023 -0600

        RISC-V: Support XVentanaCondOps extension
    
        Ventana Micro has published the specification for their
        XVentanaCondOps ("conditional ops") extension at
          https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
        which contains two new instructions
          - vt.maskc
          - vt.maskcn
        that can be used in constructing branchless sequences for
        various conditional-arithmetic, conditional-logical, and
        conditional-select operations.
    
        To support such vendor-defined instructions in the mainline binutils,
        this change also adds a riscv_supported_vendor_x_ext secondary
        dispatch table (but also keeps the behaviour of allowing any unknow
        X-extension to be specified in addition to the known ones from this
        table).
    
        As discussed, this change already includes the planned/agreed future
        requirements for X-extensions (which are likely to be captured in the
        riscv-toolchain-conventions repository):
          - a public specification document is available (see above) and is
            referenced from the gas-documentation
          - the naming follows chapter 27 of the RISC-V ISA specification
          - instructions are prefixed by a vendor-prefix (vt for Ventana)
            to ensure that they neither conflict with future standard
            extensions nor clash with other vendors
    
        bfd/ChangeLog:
    
                * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
                (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.
    
        gas/ChangeLog:
    
                * doc/c-riscv.texi: Add section to list custom extensions and
                  their documentation URLs.
                * testsuite/gas/riscv/x-ventana-condops.d: New test.
                * testsuite/gas/riscv/x-ventana-condops.s: New test.
    
        include/ChangeLog:
    
                * opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
                * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.
    
        opcodes/ChangeLog:
    
                * riscv-opc.c: Add vt.maskc and vt.maskcn.
    
        Series-version: 1
        Series-to: binutils@sourceware.org
        Series-cc: Kito Cheng <kito.cheng@sifive.com>
        Series-cc: Nelson Chu <nelson.chu@sifive.com>
        Series-cc: Greg Favor <gfavor@ventanamicro.com>
        Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
  

On Wed, 26 Apr 2023 13:28:40 PDT (-0700), Jeff Law wrote:
>
>
>
> This patch adds support for the Veyron V1's XVentanaCondOps extension.
> These instructions provide a primitive that corresponds to:
>
> x = (a eq/ne 0) ? x : 0;
>
> Ie, it's a conditional zero.  On top of this primitive the compiler can
> build a variety of branchless sequences to implement conditional
> arithmetic, logical and select operations.
>
> If you follow the RISC-V world, you'll realize XVentanaCondops is
> essentially the same as the Zicond extension that is currently going
> through the ratification process.  The only material difference is the
> instruction encoding.
>
> The Veyron V1 processor implements XVentanaCondOps, but not Zicond.
> That's simply due to timing.

Do you have a link to anything that says this?  I don't think we ever 
got a hard definition of what the requirements are, just some sort of 
annocement that the chip is going to be publicly availiable.  There's 
some stuff on the Ventana website, but it's all sort of vague marketing 
type stuff.

> This work was done by Philipp Tomsich and the VRULL team for Ventana.
> Going forward I'm the best point of contact for this code.
>
> Reviewed, tested and pushed to the trunk.
>
> Jeff
> commit 1656d3f8ef56a16745689c03269412988ebcaa54
> Author: Philipp Tomsich <philipp.tomsich@vrull.eu>
> Date:   Wed Apr 26 14:09:34 2023 -0600
>
>         RISC-V: Support XVentanaCondOps extension
>
>         Ventana Micro has published the specification for their
>         XVentanaCondOps ("conditional ops") extension at
>           https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
>         which contains two new instructions
>           - vt.maskc
>           - vt.maskcn
>         that can be used in constructing branchless sequences for
>         various conditional-arithmetic, conditional-logical, and
>         conditional-select operations.
>
>         To support such vendor-defined instructions in the mainline binutils,
>         this change also adds a riscv_supported_vendor_x_ext secondary
>         dispatch table (but also keeps the behaviour of allowing any unknow
>         X-extension to be specified in addition to the known ones from this
>         table).
>
>         As discussed, this change already includes the planned/agreed future
>         requirements for X-extensions (which are likely to be captured in the
>         riscv-toolchain-conventions repository):
>           - a public specification document is available (see above) and is
>             referenced from the gas-documentation
>           - the naming follows chapter 27 of the RISC-V ISA specification
>           - instructions are prefixed by a vendor-prefix (vt for Ventana)
>             to ensure that they neither conflict with future standard
>             extensions nor clash with other vendors
>
>         bfd/ChangeLog:
>
>                 * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
>                 (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.
>
>         gas/ChangeLog:
>
>                 * doc/c-riscv.texi: Add section to list custom extensions and
>                   their documentation URLs.
>                 * testsuite/gas/riscv/x-ventana-condops.d: New test.
>                 * testsuite/gas/riscv/x-ventana-condops.s: New test.
>
>         include/ChangeLog:
>
>                 * opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
>                 * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.
>
>         opcodes/ChangeLog:
>
>                 * riscv-opc.c: Add vt.maskc and vt.maskcn.
>
>         Series-version: 1
>         Series-to: binutils@sourceware.org
>         Series-cc: Kito Cheng <kito.cheng@sifive.com>
>         Series-cc: Nelson Chu <nelson.chu@sifive.com>
>         Series-cc: Greg Favor <gfavor@ventanamicro.com>
>         Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
>
> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
> index 19391d94e30..bd0c7c81329 100644
> --- a/bfd/elfxx-riscv.c
> +++ b/bfd/elfxx-riscv.c
> @@ -1255,6 +1255,8 @@ static struct riscv_supported_ext riscv_supported_vendor_x_ext[] =
>    {"xtheadmemidx",	ISA_SPEC_CLASS_DRAFT,	1, 0, 0 },
>    {"xtheadmempair",	ISA_SPEC_CLASS_DRAFT,	1, 0, 0 },
>    {"xtheadsync",	ISA_SPEC_CLASS_DRAFT,	1, 0, 0 },
> +  /* XVentanaCondOps: https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf */
> +  {"xventanacondops",	ISA_SPEC_CLASS_DRAFT,	1, 0, 0 },
>    {NULL, 0, 0, 0, 0}
>  };
>
> @@ -2383,6 +2385,8 @@ riscv_multi_subset_supports (riscv_parse_subset_t *rps,
>        return riscv_subset_supports (rps, "xtheadmempair");
>      case INSN_CLASS_XTHEADSYNC:
>        return riscv_subset_supports (rps, "xtheadsync");
> +    case INSN_CLASS_XVENTANACONDOPS:
> +      return riscv_subset_supports (rps, "xventanacondops");
>      default:
>        rps->error_handler
>          (_("internal: unreachable INSN_CLASS_*"));
> diff --git a/gas/doc/c-riscv.texi b/gas/doc/c-riscv.texi
> index 64fff6a7973..98d5d1bed44 100644
> --- a/gas/doc/c-riscv.texi
> +++ b/gas/doc/c-riscv.texi
> @@ -763,5 +763,11 @@ It is documented in @url{https://github.com/T-head-Semi/thead-extension-spec/rel
>  The XTheadSync extension provides instructions for multi-processor synchronization.
>
>  It is documented in @url{https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.0.0/xthead-2022-09-05-2.0.0.pdf}.
> +@item XVentanaCondOps
> +XVentanaCondOps extension provides instructions for branchless
> +sequences that perform conditional arithmetic, conditional
> +bitwise-logic, and conditional select operations.
> +
> +It is documented at @url{https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf}.
>
>  @end table
> diff --git a/gas/testsuite/gas/riscv/x-ventana-condops.d b/gas/testsuite/gas/riscv/x-ventana-condops.d
> new file mode 100644
> index 00000000000..cab0cc8dc12
> --- /dev/null
> +++ b/gas/testsuite/gas/riscv/x-ventana-condops.d
> @@ -0,0 +1,12 @@
> +#as: -march=rv64i_xventanacondops1p0
> +#source: x-ventana-condops.s
> +#objdump: -d
> +
> +.*:[ 	]+file format .*
> +
> +
> +Disassembly of section .text:
> +
> +0+000 <target>:
> +[ 	]+0:[ 	]+00c5e57b[ 	]+vt.maskc[ 	]+a0,a1,a2
> +[ 	]+4:[ 	]+00e6f57b[ 	]+vt.maskcn[ 	]+a0,a3,a4
> diff --git a/gas/testsuite/gas/riscv/x-ventana-condops.s b/gas/testsuite/gas/riscv/x-ventana-condops.s
> new file mode 100644
> index 00000000000..562cf7384f7
> --- /dev/null
> +++ b/gas/testsuite/gas/riscv/x-ventana-condops.s
> @@ -0,0 +1,4 @@
> +target:
> +	vt.maskc	a0, a1, a2
> +	vt.maskcn	a0, a3, a4
> +
> diff --git a/include/opcode/riscv-opc.h b/include/opcode/riscv-opc.h
> index 85d35c1efc9..91e56c03191 100644
> --- a/include/opcode/riscv-opc.h
> +++ b/include/opcode/riscv-opc.h
> @@ -2342,6 +2342,11 @@
>  #define MASK_TH_SYNC_IS 0xffffffff
>  #define MATCH_TH_SYNC_S 0x0190000b
>  #define MASK_TH_SYNC_S 0xffffffff
> +/* Vendor-specific (Ventana Microsystems) XVentanaCondOps instructions */
> +#define MATCH_VT_MASKC 0x607b
> +#define MASK_VT_MASKC 0xfe00707f
> +#define MATCH_VT_MASKCN 0x707b
> +#define MASK_VT_MASKCN 0xfe00707f
>  /* Unprivileged Counter/Timers CSR addresses.  */
>  #define CSR_CYCLE 0xc00
>  #define CSR_TIME 0xc01
> @@ -3236,6 +3241,9 @@ DECLARE_INSN(th_sync, MATCH_TH_SYNC, MASK_TH_SYNC)
>  DECLARE_INSN(th_sync_i, MATCH_TH_SYNC_I, MASK_TH_SYNC_I)
>  DECLARE_INSN(th_sync_is, MATCH_TH_SYNC_IS, MASK_TH_SYNC_IS)
>  DECLARE_INSN(th_sync_s, MATCH_TH_SYNC_S, MASK_TH_SYNC_S)
> +/* XVentanaCondOps instructions. */
> +DECLARE_INSN(vt_maskc, MATCH_VT_MASKC, MASK_VT_MASKC)
> +DECLARE_INSN(vt_maskcn, MATCH_VT_MASKCN, MASK_VT_MASKCN)
>  #endif /* DECLARE_INSN */
>  #ifdef DECLARE_CSR
>  /* Unprivileged Counter/Timers CSRs.  */
> diff --git a/include/opcode/riscv.h b/include/opcode/riscv.h
> index b4ae55249bb..e86a1bd0824 100644
> --- a/include/opcode/riscv.h
> +++ b/include/opcode/riscv.h
> @@ -422,6 +422,7 @@ enum riscv_insn_class
>    INSN_CLASS_XTHEADMEMIDX,
>    INSN_CLASS_XTHEADMEMPAIR,
>    INSN_CLASS_XTHEADSYNC,
> +  INSN_CLASS_XVENTANACONDOPS,
>  };
>
>  /* This structure holds information for a particular instruction.  */
> diff --git a/opcodes/riscv-opc.c b/opcodes/riscv-opc.c
> index d9d69cda548..1c3d9b0903e 100644
> --- a/opcodes/riscv-opc.c
> +++ b/opcodes/riscv-opc.c
> @@ -2009,6 +2009,10 @@ const struct riscv_opcode riscv_opcodes[] =
>  {"th.sync.is",       0, INSN_CLASS_XTHEADSYNC,  "",   MATCH_TH_SYNC_IS,       MASK_TH_SYNC_IS,       match_opcode, 0},
>  {"th.sync.s",        0, INSN_CLASS_XTHEADSYNC,  "",   MATCH_TH_SYNC_S,        MASK_TH_SYNC_S,        match_opcode, 0},
>
> +/* Vendor-specific (Ventana Microsystems) XVentanaCondOps instructions */
> +{"vt.maskc",    0, INSN_CLASS_XVENTANACONDOPS, "d,s,t", MATCH_VT_MASKC, MASK_VT_MASKC, match_opcode, 0 },
> +{"vt.maskcn",   0, INSN_CLASS_XVENTANACONDOPS, "d,s,t", MATCH_VT_MASKCN, MASK_VT_MASKCN, match_opcode, 0 },
> +
>  /* Terminate the list.  */
>  {0, 0, INSN_CLASS_NONE, 0, 0, 0, 0, 0}
>  };
  

On 4/26/23 15:09, Palmer Dabbelt wrote:

>>
>> The Veyron V1 processor implements XVentanaCondOps, but not Zicond.
>> That's simply due to timing.
> 
> Do you have a link to anything that says this?  I don't think we ever 
> got a hard definition of what the requirements are, just some sort of 
> annocement that the chip is going to be publicly availiable.  There's 
> some stuff on the Ventana website, but it's all sort of vague marketing 
> type stuff.
The processor was announced back in December at the summit which I 
thought was the requirement that you and Philipp had worked out.

We're still waiting on hardware for bring-up.  But in terms of the 
processor features/ISA, that's immutable at this point (as much as I 
wish that weren't the case).

jeff
  

On Wed, 26 Apr 2023 14:16:10 PDT (-0700), Jeff Law wrote:
>
>
> On 4/26/23 15:09, Palmer Dabbelt wrote:
>
>>>
>>> The Veyron V1 processor implements XVentanaCondOps, but not Zicond.
>>> That's simply due to timing.
>>
>> Do you have a link to anything that says this?  I don't think we ever
>> got a hard definition of what the requirements are, just some sort of
>> annocement that the chip is going to be publicly availiable.  There's
>> some stuff on the Ventana website, but it's all sort of vague marketing
>> type stuff.
> The processor was announced back in December at the summit which I
> thought was the requirement that you and Philipp had worked out.

We had the various RISC-V port maintainers and long-term contributors in 
FSF toolchain land (ie, binutils/GCC/glibc) agree on something posted to 
the mailing list.

Philipp and I certainly talked about it, but there's no private 
agreements or anything like that -- it's just what we discuss on the 
mailing lists.  Unfortunately he has along history of misrepresenting 
things, but that's really why we're so careful about making sure that 
all the decisions are talked about on the lists.

> We're still waiting on hardware for bring-up.  But in terms of the
> processor features/ISA, that's immutable at this point (as much as I
> wish that weren't the case).

The idea was to have some sort of timeline around availability of the 
hardware -- essentially the goal is to avoid being stuck supporting 
stuff that doesn't actually make it out of the lab.  I can't find 
anything that actually says that, but then also I'm pretty much allergic 
to chip company marketing material these days so I sort of stay out of 
it ;)

The best I've been able to find is this "Veyron V1 is Highest 
Performance RISC-V Processor running at 3.6GHz in 5nm" [1].  The 
big-ticket ones like an SDK and dev board don't seem to exist anywhere 
outside of press releases, though (there's a github [2], but no SDK).

I know it's kind of pedantic, but we've had a lot of issues in the past 
with RISC-V folks making stuff up and trying to push around upstream.  
I'm not saying you're doing that, you've been around long enough that if 
you say you have a chip I believe you.  The goal is to be fair to 
everyone, though -- essentially the same as what happened for the GCC 
patches.

1: https://www.ventanamicro.com/ventana-introduces-veyron-worlds-first-data-center-class-risc-v-cpu-product-family/
2: https://github.com/ventana-micro-systems
  

On 4/26/23 15:42, Palmer Dabbelt wrote:
> We had the various RISC-V port maintainers and long-term contributors in 
> FSF toolchain land (ie, binutils/GCC/glibc) agree on something posted to 
> the mailing list.
> 
> Philipp and I certainly talked about it, but there's no private 
> agreements or anything like that -- it's just what we discuss on the 
> mailing lists.  Unfortunately he has along history of misrepresenting 
> things, but that's really why we're so careful about making sure that 
> all the decisions are talked about on the lists.
I wasn't implying any private communications.  It was more a reflection 
that you and Philipp seemed to be the principals in the overall discussion.

My recollection from the discussion back in Nov/Dec was that the only 
thing we were still waiting on for xventanacondops to move forward was 
an announcement of the chip.  My understanding was the chip didn't need 
to actually be available yet.  Maybe I'm mis-remembering, and if so, 
I've got no problem pulling this out.

Perhaps the requirements should be posted somewhere so that gcc, 
binutils, gdb, glibc, etc can all refer to and follow the same 
procedures for accepting vendor specific bits.

> 
> The idea was to have some sort of timeline around availability of the 
> hardware -- essentially the goal is to avoid being stuck supporting 
> stuff that doesn't actually make it out of the lab.  I can't find 
> anything that actually says that, but then also I'm pretty much allergic 
> to chip company marketing material these days so I sort of stay out of 
> it ;)
I don't recall a timeline in the requirements.  But again, it's been 
months since we kicked this stuff around.  I can't speak to timelines 
other than "we're waiting on hardware to start bring-up".


> 
> The best I've been able to find is this "Veyron V1 is Highest 
> Performance RISC-V Processor running at 3.6GHz in 5nm" [1].  The 
> big-ticket ones like an SDK and dev board don't seem to exist anywhere 
> outside of press releases, though (there's a github [2], but no SDK).
I don't think we've released our SDK to anyone except partners.  So no 
surprise you can't find an SDK :)

> 
> I know it's kind of pedantic, but we've had a lot of issues in the past 
> with RISC-V folks making stuff up and trying to push around upstream. 
> I'm not saying you're doing that, you've been around long enough that if 
> you say you have a chip I believe you.  The goal is to be fair to 
> everyone, though -- essentially the same as what happened for the GCC 
> patches.
No worries.  As I've noted in the past, I'm keenly aware of the desire 
to avoid even the appearance of unfairness or someone taking advantage 
of their position in the communities.  It's something that's been 
important to me personally for decades in the GCC space, so you don't 
ever have to worry about explaining it to me or offending me by being 
pedantic in this space.

I'm not going to lose any sleep if we need to delay bits for veyron-v1, 
I just want to make sure we have an agreed upon process so that we know 
when things can go forward across the various tools.  I'm actually more 
concerned about this for gcc than binutils/gdb as we have scheduler 
models, costing models, etc that I'd like to get submitted.  I've held 
off doing that for the duration of the gcc-13 cycle, but very much want 
to see those things move forward in the gcc-14 cycle.

So in summary, let's get the agreement/policy posted in a easily found 
location.  I'll suggest the GCC wiki, but I'm certainly not wed to that 
idea.

jeff
  

On Fri, 28 Apr 2023 11:43:50 PDT (-0700), jeffreyalaw@gmail.com wrote:
>
>
> On 4/26/23 15:42, Palmer Dabbelt wrote:
>> We had the various RISC-V port maintainers and long-term contributors in
>> FSF toolchain land (ie, binutils/GCC/glibc) agree on something posted to
>> the mailing list.
>>
>> Philipp and I certainly talked about it, but there's no private
>> agreements or anything like that -- it's just what we discuss on the
>> mailing lists.  Unfortunately he has along history of misrepresenting
>> things, but that's really why we're so careful about making sure that
>> all the decisions are talked about on the lists.
> I wasn't implying any private communications.  It was more a reflection
> that you and Philipp seemed to be the principals in the overall discussion.

That's probably how it looks publicly, but it's not how it happens in 
practice.  Essentially we have an off-list discussion with the various 
maintainers/contributors who do RISC-V stuff, and then go post the 
result of that on the list.

I actually don't like doing things that way, I'd prefer to do things in
public.  That's how we used to do it, but we ended up with so much
trouble from the folks at the RISC-V foundation that we stopped.

I'm not opposed to trying to have the discussions in public again,
though.  It doesn't really impact me personally because I take all the
heat for posting these publicly, so it's really up to everyone else.

> My recollection from the discussion back in Nov/Dec was that the only
> thing we were still waiting on for xventanacondops to move forward was
> an announcement of the chip.  My understanding was the chip didn't need
> to actually be available yet.  Maybe I'm mis-remembering, and if so,
> I've got no problem pulling this out.
>
> Perhaps the requirements should be posted somewhere so that gcc,
> binutils, gdb, glibc, etc can all refer to and follow the same
> procedures for accepting vendor specific bits.

There's a thread here: 
https://inbox.sourceware.org/gcc-patches/mhng-289aa2f5-86f4-4cdb-bed5-1ce130ddc841@palmer-mbp2014/

It doesn't look like we came to an agreement, though.  The only concrete 
place we wrote things down was in Linux: 
<https://docs.kernel.org/riscv/patch-acceptance.html>.  That's stricter 
than the toolchain side of things, though, as it specifically requires 
vendors to have a history of shipping before we take 
pre-publicly-availiable hardware.

>> The idea was to have some sort of timeline around availability of the
>> hardware -- essentially the goal is to avoid being stuck supporting
>> stuff that doesn't actually make it out of the lab.  I can't find
>> anything that actually says that, but then also I'm pretty much allergic
>> to chip company marketing material these days so I sort of stay out of
>> it ;)
> I don't recall a timeline in the requirements.  But again, it's been
> months since we kicked this stuff around.  I can't speak to timelines
> other than "we're waiting on hardware to start bring-up".

IIRC the core of it was this "we'll take the support, but if the 
hardware doesn't show up on whatever timeline was announced then we'll 
aggressively remove it".

That said, I can't find anything.

>> The best I've been able to find is this "Veyron V1 is Highest
>> Performance RISC-V Processor running at 3.6GHz in 5nm" [1].  The
>> big-ticket ones like an SDK and dev board don't seem to exist anywhere
>> outside of press releases, though (there's a github [2], but no SDK).
> I don't think we've released our SDK to anyone except partners.  So no
> surprise you can't find an SDK :)
>
>>
>> I know it's kind of pedantic, but we've had a lot of issues in the past
>> with RISC-V folks making stuff up and trying to push around upstream.
>> I'm not saying you're doing that, you've been around long enough that if
>> you say you have a chip I believe you.  The goal is to be fair to
>> everyone, though -- essentially the same as what happened for the GCC
>> patches.
> No worries.  As I've noted in the past, I'm keenly aware of the desire
> to avoid even the appearance of unfairness or someone taking advantage
> of their position in the communities.  It's something that's been
> important to me personally for decades in the GCC space, so you don't
> ever have to worry about explaining it to me or offending me by being
> pedantic in this space.
>
> I'm not going to lose any sleep if we need to delay bits for veyron-v1,
> I just want to make sure we have an agreed upon process so that we know
> when things can go forward across the various tools.  I'm actually more
> concerned about this for gcc than binutils/gdb as we have scheduler
> models, costing models, etc that I'd like to get submitted.  I've held
> off doing that for the duration of the gcc-13 cycle, but very much want
> to see those things move forward in the gcc-14 cycle.
>
> So in summary, let's get the agreement/policy posted in a easily found
> location.  I'll suggest the GCC wiki, but I'm certainly not wed to that
> idea.

I'm fine with that.