Relax constraint on vl exceeding register group effective VLEN.

[David-Horner]

With the two significant changes of
a) V0.9 register structure moving from vertical to horizontal widening and
b) eliminating SLEN
element width structural dependencies are eliminated.

As a consequence maintaining SEW/LMUL ratio is also removed.

This allows software to address a register groups operated as two or more consecutive but separate register groups..

Currently a vsetvl[i] instruction would be needed to set a lower LMUL.
However, it would be advantageous to allow a lower than LMUL aligned register group to execute when vl > EMUL/EEW.
In this case only the first EMUL/EEW elements are processed.

This would be especially useful in transforming a fully populated LMUL=8 register group two LMUL=4 groups with the lower elements remaining unchanged and the upper being volatile. (more valid combinations are possible)

The drops a run time alignment check that is a worthwhile trade-off to provide the functionality.

I believe this is a viable post V1.0 relaxation.
So, I believe it should also be consciously assessed for V1.0.

This is complimentary to #523

table of valid combinations

LMUL	r	r+1	r+2	r+3	r+4	r+5	r+6	r+7
8	8	1	2	1	4	1	2	1
4	4	1	2	1
2	2	1

[David-Horner]

#397 Allow widening and narrowing instructions to execute in LMUL=8
can be incorporated into this request. The concerns are similar and we thus need not re-open #397 that was closed primarily based on SLEN concerns.

[David-Horner]

from #397

To me the only compelling argument for excluding limited LMUL=16 was SLEN complexities which are now removed.

I agree that burdening all implementations with limited LMUL=16 support is undesirable.
However, we appear to be now a base "V" that targets unix/application use.
Specific configurations for it (such as VLEN>=128) are irrelevant for other domains that may have a minimal Vminus implementation.
Just as VLEN=256/512 have diminishing returns for LMUL=16, VLEN=64 and VLEN=32 have increasing value for it.

To have such usage supported by compilers and vtype-tracking assemblers, with compile time tags and warnings respectively, helps to provide the broad platform support that was intended/envisioned.

The same is also true for the other relaxation I request here.

It need not be part of V but may well be in a V+ addendum that we anticipate other platform "profiles" to adopt.
To the extent that the Software Eco System keeps such in mind, the better the overall product might be and the more extendable its base may become. This is, after all, what I understood to also be one of our primary goals.

[David-Horner]

Can we add to the V addendum #530 these to be resolved after V1.0 issues?
That would help give guidance on what parts of the design are being considered for relaxation and will allow ecosystem builders the possibility to retain flexibility, rather than hard-coding to the V1.0 spec.