I disagree that #460 should be deferred until after V1.0.

Although I agree that the proposal itself can be implemented in a manner consistent with the current vsetvli definition,
I disagree that the larger issue of how to expand vsetvli immediate bits is sufficiently addressed to make the decision to defer.

As a result I ask that at least the larger issue be addressed for V1.0.

As background, #440 is a refinement of an approach to encode vtype bits in vd and vs2 fields.
The details are on github and references to like prior proposals

I posted on #440 this response to labeling it "Resolve after V1.0".:

Although technically not a part of this proposal, the decision to defer until after V1.0 would greatly impact proposal #460.

As we are down to one vsetvli immediate bit, and all used bits consume all combinations as valid, we are at the cusp where we should consider the impacts of expansion.

Expansion requires providing at least one of the following:

1. a vsetvli with a larger vsetvli encoding (one bit can be immediately recovered if we allocate vsetvl elsewhere)
   allowing full configuration withing a single instruction.
   Opcode space is constrained so the expansion would be at best a few bits.
2. variants of the vsetvli instruction that windows successively smaller immediate values into vtype.
   necessitating splitting full configuration over two (or more) instructions.
3. variants of vsetvli that repurpose vd and/or vs2 as immediate fields, with or without calculating vl.
   necessitating splitting full configuration over two (or more) instructions.
4. multiple vsetvli-like instructions
   (this is the mechanism required for custom RVV to change custom vtype bits)
   necessitating splitting full configuration over two (or more) instructions;
   unless it introduces a larger footprint vsetvli-like instruction as in option 1.
5. a revision of vsetvli that encodes vtype bits into the vd and/or vs2 fields
   allowing full configuration withing a single instruction. see #460

Splitting configuration over two immediate format instructions is problematic.
It will in some cases cause transient vill state necessitating a mechanism to allow such transition, maintaining at least partial state from prior vsetvli variants (likely relaxing the all bits cleared but vill constraint), or a software fall back to vsetvl method.

Option 1 must be decided before V1.0 (otherwise it becomes an option 4 with two overlapping instructions)

Options 2 through 5 can be deferred until after V1.0 but each have impacts to

• hardware fragmentation
  pressure/necessity to support variants even if the functionality is not present
  trapping on variants to emulate new variants that are introduced for unused functionality

• software ecosystem complexity to
  address the hardware fragmentation (if they care)
  e.g. conditional vsetvli variant execution dependent upon "model"
  optimize the appropriate alternative means to configure a given setting
  e.g. hoisting one of the variants out of the loop to allow a single immediate vsetvli variant
  There could be multiple competing two (or more) step split update approaches.

Options 2 through 4 have the additional concerns of:

• appropriate design of variants to minimize the hardware/software eco/split configuration effects
• extension of vtype model to accommodate split configuration updates

Deferred options 2,3 and 5 need not trap on V1.0 machines as vill would be set if the remaining bit is used to differentiate.

Deferred option 4 will always trap on V1.0 machines.

Option 5 is a novel approach to the problem.
If it is deferred until post V1.0

• we can expect confusion over two disparate approaches
• the encoding into vd/vs1/vs2 will subsume the original to avoid split updates
  . as a result confusion will be compounded as the old format falls out of use, but old code persists
  . hardware will need to support both
  increasing what has been considered a critical path on this list
  even though the old format is obsoleted