TL;DR;

Point of agreement #1 - x0,x0 variant should not change vl.
I believe we are also in agreement on

#2 - if vl would change because of a SEW/LMUL change vill should be set.

Outstanding questions:

#3) If vill is set should vl remain unchanged? (I vote for yes).

#4) Should potential change of vl  set vill? Currently that condition is equivalent to a SEW/LMUL ratio change.

    4a) in all cases? even if vl is zero? even if vl is 1? (this rule has fringe cases).
    4b) what do we do when another vtype parameter is added that also would potentially change vl?
            What is the likely formulation of such an algorithm?
            In general something comparable to a simple ratio would be inadequate.
            I believe this SEW/LMUL formulation is not future proof.

#5) Why not defined the x0,x0 variant that doesn't change vl as succeeding if vl doesn't change?
       Only setting vill if the resultant new-vl does not match the previous vl.
          (Point #3 is still relevant, but there are no longer any corner cases as in 4a and 4b).

Krste below expresses some reasons that lean towards SEW/LMUL invariance rather than vl invariance be the determinant for setting vill.

Specifically, comparing vl to the new-vl requires reading the old vl and that is potentially expensive, why not avoid the read of vl altogether?

One approach is based on #4.
Instead read previous(current?) vlmul and vsew, calculate ratio, compare with new ratio and set vill if different.
We can avoid vlmul/vsew read by retaining the current SEW/LMUL values (or ratio)
(can be stored locally, only 6 bits for vsew and vlmul)
and compare that to the new SEW/LMUL ratio.
quite efficient.

What of advocating for #5 - what is the overhead here?

A simplistic approach can read vl and push it through the existing circuitry,
  except when the calculated MAXVL exceeds the calculated vl set vill
otherwise leave the current vl alone (or overwrite it with itself, whichever).
For simple designs there is a simple implementation that can further be optimized by setting vill  on a slow path.

Alternatively we can use the SEW/LMUL optimization approach:
We can store the vl info locally.
For standard V minimum (log2(VLEN*8); log2(128) + log2(8) = 7 + 3 = 10 bits,
with an additional bit per doubling of VLEN) .
We compare the calculated vl with that.
This compares favourably to #4 optimization.

But we can do better than that.
We only need compare calculated MAXVL
(comparable computational cost to SEW/LMUL ratio)
which is normally done anyway (so can leverage existing circuitry)
and compare that to locally stored vl information.
MAXVL varies from 1 (in the worst case) to VLEN*8.
As MAXVL is always a power of 2 the number of bits to store is log2(log2(VLEN*8)) or 4 bits for up to VLEN=2K.
Thus 4 bits for the locally saved vl information which is the minimal MAXVL for current vl.
(V minimum is ELEN=64 and VLEN=128 which is among the case for which 3 bits suffice)
I'm not a circuit guru, but "MINVL" from vl is inexpensive  to calculate,
 especially as it also does not need to be on the critical path for non- x0,x0 variants
  that are the only ones that need store vl info locally.
.

It would appear that #5 is a net win for circuitry and a better formulation of vl unchanged requirements.

#5 now has my vote.

I provide further analysis within the replies below.

On 2020-07-22 8:21 p.m., Bill Huffman wrote:

I agree with Krste's support for Guy's proposal here.

thanks for the response.

Loops with
multiple element widths are likely to have more non-vl-changing
instructions than vl-changing instructions. Knowing this from the
instruction without having to track the sequence involved is likely to
pay benefits in implementation.

an Important and valid point that I also support.

Bill

On 7/22/20 4:35 PM, Krste Asanovic wrote:

EXTERNAL MAIL



The main issue is whether the current PoR has any useful purpose when
vl changes.

I disagree with characterizing this as the main issue.
I agree that it is an important consideration.

The pivotal question as I see it is, what action the instruction should take when vl would change.
PoR says change it, as any other vsetvl variant would.

I don't subscribe to "field of dreams" approach. I tried
to find some scenarios hoping there would be some useful cases, but
struggled to come up with anything substantial with current PoR.
There are certainly some possible alternate vl-changing behaviors that
could be useful, but those would be a different instruction. Unless
there is a clear use, the additional vl-modifying behavior in PoR
cannot really be stated as a positive but only a curiosity.

Until such a use is discovered.

I don't disagree that it is an important consideration, only that it is secondary.
If explicitly disallowing the "apparently useless" behaviour itself causes substantial cost, we can live with a meaningless instruction formulation.
RVI frequently allows formulations that lacking a clear and compelling use case because
 it is an artifact of the general useful operation, that to exclude it would increase overhead (instruction decode , etc.)
e.g. bne rs1,rs2,-2, branch to within the same instruction which, depending upon rs1/rs2 values can be a C.BNEZ infinite loop if a specific register (x8 through x15) is non-zero.
The same could hold true here. In my opinion, this is substantially why (this was main part of my reasoning),  the current PoR was adopted.

Bill expresses succinctly:

Loops with multiple element widths are likely to have more non-vl-changing
instructions than vl-changing instructions.

It is precisely due to the nature of its expected (lack of) use,
that in other situations we would disregard the low use and esoteric case as harmless.
Consider the reluctance to reserve RVV simm5/rs1=0 formulations that match an existing simpler instruction.
However, in this case I agree that the formulation x0,x0 is valuable to use effectively, solely because vsetvli is so important.
Even as a secondary consideration, lack of usefulness is disturbing for a dominant feature.

On the negative side, a microarchitecture will have to assume
vl will be read and written by this instruction, even if it almost
never changes.

That is PoR and I believe there is now general agreement (3 to zero so far) that changing vl is not the desired behaviour.
So, Point of agreement #1 - x0,x0 variant  should not change vl.

Even for simple machines, this will probably cause
some extra flops to be clocked.

Let's put this into perspective - all other vsetvl variants write vl, that is the primary purpose, it is explicitly in the name.
We are proposing an optimization for what we anticipate (reasonably) to be a common used case, as Bill stated.
The potential is to save some flops by avoiding the write (and delays caused by its cascade/flow/synch effects) .

For machines with renaming, it can
require a new physical vl is allocated early in machine even if vl
rarely changes. There might be microarch techniques to recycle vl
regs more quickly once known not to change, but would be much simpler
not to have to deal with this.

Agreed.  Another check for the Point of agreement #1

The (certification)verification cost alone is a big
negative for a feature that could be rarely/never used.

Agreed.  Another check for the Point of agreement #1

These instructions will likely be common in loops dealing with
multiple element widths (a common loop will have only one vsetvli that
changes vl and potentially many that manipulate SEW/LMUL), and so
optimizing their implementation is important. Having a hardware
instruction that is "change vtype but not vl, or error" is clearly
useful I think.

Agreed.  The above argument restated as for the Point of agreement #1

The dynamic debug aspect, I agree is relatively minor, but given the
prevalence of "change vtype but not vl" instructions, it is only a
positive that bugs are caught even if not always with clear
determination of problematic instruction (though I guess it will very
rare that the bug will be difficult to find even if only trap on use).

Expressed as not as persuasive, but at least a fraction check for the Point of agreement #1.

Even though I view dynamic debug as a minor benefit, I think even that
minor concrete benefit outweighs the unknown abstract benefit of
"change vl" behavior, unless there are some great use cases for the
existing PoR scheme that we've missed.

I agree.

But we cross a line to believe the objective is "that bugs are caught".
What bug is it that we believe we can design hardware to catch?

As a database analyst, I told the application developers with whom I worked
   that their compiled and running program was not "wrong".
It was doing just fine exactly what they directed it to do.
It was the perfect program for a problem other than the one they wanted to solve.

Ditto for bugs. Behaviour that one programer wants to avoid another may intend.

We cannot solve bugs in hardware. CICS attempts to do so are infamous.
All we can do is provide operations that do exactly as they are stipulated, ideally with no corner cases, with a simple conceptual definition.

Enforcing a perceived good software/"expected use" policy is rarely directly achievable or desirable.
Keep  SEW/LMUL ratio invariant is a policy/"expected use case".
I contend there are deliberate exceptions to this policy, or, in the alternative,  at minimum the policy has a limited domain.
If there are exceptions or the domain is limited it is not a good characteristic to enforce, even as a special instruction formulation.

Rather, a better characteristic to enforce is the vl in-variance in a special formulation.
It follows from the instruction formulation in which no explicit AVL is supplied (X0).
It is the underlying characteristic in the checks above and below.

But again, the implementation saving from not having to worry about
dynamic vl changes for these instructions to me far outweighs the
other issues.

Krste

On Wed, 22 Jul 2020 09:02:03 -0400, "David Horner" <ds2horner@...> said:

| I wholeheartedly agree with resolving on the mailing list.
| This should be the rule not exception.


| On 2020-07-21 11:58 p.m., Krste Asanovic wrote:
|| I want to bring this to group's attention as I think I've convinced
|| myself that Guy's suggestion is the correct path to follow, i.e.,
||
|| vsetvli x0, x0, imm
||
|| will raise vill if the new SEW'/LMUL' ratio is not the same as the old
|| SEW/LMUL implying vl might change. Similarly for vsetvl version.
| My considerations for allowing vl to change were

| a) having a compelling reason to change PoR.
|      vsetvl[i]is extremely important to RVV success.
|      It deserves deep scrutiny.
|      Challenging each and every change,
|     as well as proposing any plausible enhancement
|     are equally important to get this feature,
|     more so than others, right(tm).

| b) tracking assemblers and compilers could present warnings.
|      Part of my support was my bias towards encouraging vl tracking
| support.
|      Tracking vl in code has substantial benefits beyond a replacement
| for this x0,x0 behaviour.
|      I believe RVV success and adoption will be substantially hampered
| without it.I believe that ultimately IOT machines will benefit from RVV
|          if we continue to emphasize  simplicity  the design.
|      It is however specific to RVV.
|      So marginal hardware support that appears to mitigate a need for
| vl tracking gets a check in the negative column.

| c) A perceived simplicity of PoR for minimal designs.
|      I am biased toward ensuring simple machines can efficiently
| support for RVV.

|      Initial uptake is likely to be in the application/HPC domain, but
|      I believe that ultimately IOT machines will benefit from RVV
|          if we continue to emphasize  simplicity  the design.

| d) Setting vill is excellent as a means to avoid trap behaviour.
|      however it requires explicit check after vtype setting ops.
|      Opportunistic approaches will rely on the subsequent fault.
|      This situation is theoretically impossible to statically backward
| trace.
|      A given RVV data instruction could be branched to from anywhere,
|          conditional execution could have executed any vsetvl instruction
|          with virtually any rs1 value.
|      This biases me away from setting vill, in the x0,x0 case setting
| vl avoid vill set.
|      However, in practice branching into a loop will be errant
| behaviour and
|         RVV data instructions will be paired with a vsetvli instruction.
|      My paranoia causes me this too heavily at times. (.... reweighing
| risks)


| e)  in the x0,x0 formulation, vsetvli cannot determine from immediate
| parsing alone vill state.
|      we have strived to ensure the immediate format will meet virtually
| all in loop use cases.
|      Ideally, vsetvl is reserved for context switch (and custom)
| situations.
|      I considered x0,x0 a punt to vsetvl (potentially slow) path to
| allow for the immediate form optimization
|      (i.e. no vill setting considerations after parse) .
|      However, reweighing the benefit of retaining vl and requiring a
| late setting of vill.
|      Given vill setting can always be performed on a slow path
|      with little real impact to normal code ....  reweighing risks.


|| Apart from the debugging motivation that Guy presented,
| see my point d.
|| I would add
|| that this definition effectively removes any read or write of vl from
|| the instruction, possibly removing hazards and simplifying dependency
|| tracking and relieving an OoO machine from providing a new rename
|| register for vl (might still need for vtype).
| this does not talk to my point c.
||
|| I could not find any non-esoteric use for the vl-trimming behavior of
|| the current PoR for larger SEW/LMUL,
| I've found coders and compiler writers collectively more ingenious than I,
|  not only more eyes in free software but a spectrum of inner-eye
| perceptions and mindsets.

| So although relevant to the discussion, in the negative it is not
| compelling as a benefit.
|| so given these benefits I move we
|| adopt the "sets vill for non-iso SEW/LMUL" meaning.

|| The circuit has
|| to calculate (vsew_new-vlmul_new)!=(vsew_old-vlmul_old) to determine
|| vill, but now never needs to read
| I disagree with this behaviour. increasing VLMAX does not invalidate
| current vl and should not" raise an exception" even indirectly.
| If we are needing a warning , let assembler/compilers do it note b above.

| I also disagree that we always set vill if VLMAX reduced but vl is still
| < newVLMAX.
| Only if the ratio changes do we need to read vl, so in the frequent case
| I agree vl read can be avoided.
| To avoid a vl read
|| or write vl.
| My principle is hardware should not attempt to debug or correct software.
| Although hardware developers may believe a specific
| validation/verification facility will be useful to programmers (SEW/LMUL
| in-variance checking)
| such "policy" should not be imposed but rather a means to electively
| support such a policy be provided.
| Setting vill when original vl cannot be maintained is valid, enforcing
| an invariance policy is not.
|| ...
|| As a general optimization guide, software should endeavor to use this
|| form instead of passing in AVL to avoid the vl update when not
|| necessary.
| I agree.
| This is what was envisioned by providing x0,x0.
| Further, this encoding implies an intent which makes code clearer.
| Someone doing tricks needs to add a comment.

| I'm leaning to accepting the proposal as I amended.
||
|| I hope this is one we can resolve on the mailing list to save time in
|| the next meeting.
| as do I.
||
|| Krste
||
||
||
||


|