I appreciate you not punting this to "profiles" However, isn't this "mutually supported" effectively a profile constraint or consideration? Should we therefore include in the note that the specifics n

I trust this is not just noise. A laundry list of concerns Assess objectives and those met as we approach v1.0 of RVV Polymorphism has not made it into RVV V0.9 Tagging registers with a datatype is no

TL;DR; I make clarifications on meeting minutes. I propose we present 1) a relaxed RVV memory/process model, more relaxed than we believe current implementations require for optimal performance. Appli

No problem, happy you did. The very special nature and functionality of vsetvli justifies considering special encoding. All the following are valid considerations. None of which have been quantified.

I think I understand how I confused the situation. Issue #458 introduced idea of using rd and rs1 values to encode more bits for vsetvli. I proposed that this become the only vsetvli format. Krste cou

It is a planned extension, that even if not implemented as currently proposed it will likely consume at least 2 bits in vtype. Do you envision a possibility that it will consume no vtype bits? The rea

minor typos; substantial correction: also throughout the email vd should be rd vs1 should be rs1 And vs2 is completely bogus. Sorry I didn't catch this sooner.

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 l

I don't agree that #478 should be closed for the reasons given. I do agree that another approach might be better to superseded that which was originally proposed. But I do not agree with the proposed

The wide register being the destination, correct? Not sure I follow this, which two registers? If physical registers, then no. That design was the v0.8 method of vertical cycling through physical regi

I will make a stab at even and odd layout for widening. 5) two versions of the widening ops are defined one for even and one odd. The registers are divided into even:odd pairs. Two versions of the wid

These decisions are not made independently. E.g. Removing expanding loads led to fractional register mode. I believe there are other considerations that affect a definitive decision. 1) The even/odd a

I agree that this should be default or base configuration. I believe the extended fractional layout is a 6th approach. Issue 465. Does it qualify as a known option? As with option 2 load and stores fo

There hasn't been any traffic on this feed about vector layout, and specifically about v0.9 SLEN size standards. So I will add my thoughts here with the hopes that I will not take excessive time durin

I'm not sure how to interpret this table (been puzzling over it). But I believe the LMUL>1 case for v0.9 is incorrect for the same reason as in the previous table. For v0.9 LMUL=1 and LMUL>1 have the

The very significant correction is that for v09 SLEN=VLEN memory ordering IS preserved for LMUL>1 should be v08 v09 Grigoris LMUL>1 SLEN=VLEN memory ordering lost memory order retained memory ordering

I made this into its own thread as well. I think there is a parallel in the in-register/in-memory issue and memory consistency model/methods. The complexity of consistency models and methods is enormo

I have some suggestions for the reasons for moving from v0.8 vertical striping to v0.9 horizontal SLEN (interleave) Under v0.8 A) when vl < VLEN/SEW*LMUL the top elements are not filled. This can lead

I believe this can be weakened to required: select-able distribution patterns that are sufficiently compatible that they avoid fragmenting the software ecosystem.

This is v0.8 with SLEN=8.