search

riscvarchive / riscv-v-spec

Working draft of the proposed RISC-V V vector extension
https://jira.riscv.org/browse/RVG-122
Creative Commons Attribution 4.0 International
981 stars 272 forks source link

Largest element index is vague #873

Open jrahmeh opened 1 year ago

jrahmeh commented 1 year ago

Section 3.7 says: 

The use of vstart values greater than the largest element index for the current SEW setting is reserved.

Is the largest element index computed using the current group multiplier, or the largest group multiplier (8)? For load and store operations with explicit element width (example: vle8.v), do we use the current SEW in vtype or the effective element width (8 for vle8.v)?

hdelassus commented 1 year ago

This was fixed by #850 (emphasis mine):

The use of vstart values greater than the largest element index for the current vtype setting is reserved.

I think it would make sense to me if the EEW applied to the largest element index calculation for load/store ops with explicit element width.

aswaterman commented 1 year ago

@hdelassus Yes, you're definitely right about that. Can you make a PR that makes the wording more precise? I think it needs to factor in not just EEW but also EMUL, right?

~Actually, on further thought, isn't it correct as-is? Because the larger-EEW operands also have EMUL adjusted by the same factor, simply using SEW and LMUL (as the current text suggests) is equivalent to using EEW and EMUL for the widest type.~

Whole-register loads and stores are a counterexample to the struckthrough text, since their EEW:EMUL ratio might not be equal to the SEW:LMUL ratio. I think you're right that "EEW and EMUL of the widest operand" is correct, but so would be "EEW and EMUL of the narrowest operand", since they have the same ratio for all standard instructions. Not sure what the best phrasing is.

jrahmeh commented 1 year ago

How about: "The use of vstart values greater than the largest element index is reserved. The largest element index is determined using the effective element width and effective group multiplier of the current instruction."

hdelassus commented 1 year ago

@hdelassus Yes, you're definitely right about that. Can you make a PR that makes the wording more precise? I think it needs to factor in not just EEW but also EMUL, right?

Sounds about right to me. Also, @jrahmeh's suggestion LGTM.

Whole-register loads and stores are a counterexample to the struckthrough text, since their EEW:EMUL ratio might not be equal to the SEW:LMUL ratio.

Also mask loads and stores, which have EEW=8 and EMUL=1, right?

aswaterman commented 1 year ago

Also mask loads and stores

Yes, those, too.

Would either of you mind making a PR?

nick-knight commented 1 year ago

Not 100% sure, but we might need a similar modification to a subsequent statement:

Implementations are permitted to raise illegal instruction exceptions when attempting to execute a vector instruction with a value of vstart that the implementation can never produce when executing that same instruction with the same vtype setting.

I've always been a little confused about potential overlap between this statement and the earlier one being debated in this issue. So take my comment with a grain of salt.

aswaterman commented 1 year ago

@nick-knight I think that one should stay as-is. Implicitly, it admits the possibility that the constraints on vstart depend on the opcode, or on vtype, or on a combination of the opcode and vtype. So it covers all bases.