Hello Guy,

It definitely would be good for Zve to be a strict subset of V.  I think that means the same thing as that any binary that runs on Zve will run correctly on Z.  But I’m not seeing how any code that runs on a Zve compliant core with VLEN < 128 will fail to run on V.  Do you have an example?  Is there a further relaxation that I’m not thinking about besides VLEN < 128?

Separately, I don’t think we can add an option that restricts.  All code that will run without an option should run with the option.  But I think V may be able to be a superset without that.

      Bill

-----Original Message-----
From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Friday, July 2, 2021 12:53 PM
To: tech-vector-ext@...
Subject: [RISC-V] [tech-vector-ext] Vector TG meeting minutes 2021/07/02

EXTERNAL MAIL

Date: 2021/07/02

Task Group: Vector Extension

Chair: Krste Asanovic

Vice-Chair: Roger Espasa

Number of Attendees: ~12

Current issues on github: https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec__;!!EHscmS1ygiU1lA!RMBBi1gNhOHzOU2abQmClNEMWkaI2-aaN2062y7AMPrW99eX1JSWR8QC9lFNZlI$

We discussed several issues that will result in clarifications to the current spec, but no substantive changes.  The plan is to release a

v1.0-rc2 next week, then have a (hopefully) final meeting next week before releasing for public review.

#701 Whole register mask loads

The group revisited the decision to exclude these from the v1.0 spec.

The discussion concluded that the use was narrow (code that knew the target register would be used as a mask, but where vector length was different than current vector length), and that the effect could be synthesized with a four instruction sequence to save vl, set max vector length, then use mask load, then restore vl (in some cases, a portion of the vl manipulation could possibly be amortized with other code).  The decision was to continue to exclude these from v1.0 and the spec commentary will be updated to describe the alternative code sequence.

I think having the exact instruction sequence will both help clarify support for wide, re-organizing datapaths and ensure that the envisioned sequence isn't only 99% correct.

#702 Reductions when vl=0

The group discussed the behavior of reductions when vl=0, and concluded we'd retain the current definition.  This only affects the case where the source and destination scalar are in different vector registers, which was determined to be a rare case that would often be known statically in code.  Commentary will be added to text to provide rationale.

Not just the rational but what cases need particular care to avoid unexpected behavior.

     Bill

#703 Clarify that vl=0 does not affect moves from vector registers

After reviewing #702, it was realized the current text could be confusing for the effect of vl=0 on vector->scalar move instructions, so the text will be clarified.

#704 Add vector memory operations to RISC-V MCM

As already noted in spec, a more formal definition of vector memory operations interaction with MCM is needed.

#705 Vector memory operations under TSO.

While not necessary for v1.0 (as Ztso is still not ratified, though frozen), the group realised that the behavior under RVTSO needs to be clarified.

#664 drop tail undisturbed

This closed issue was raised again.  The group agreed that tail undisturbed caused implementation complexity for renamed/OoO implementations, but also acknowledged there were some important use cases for tail undisturbed.  The observation was made that the complexity for renamed/OoO machines mostly arises from optimizing for performance, so implementations that did not care about tail-undisturbed use cases could simplify microarchitecture.  A note will be added explaining this tradeoff.

I did not expect that this meeting, of all meetings, would be cancelled.

So I’ll send my comments by email now rather than discussing an important one at the meeting and filing issues for minor ones.  I think #1 is important.  The rest are lesser comments:

1. I’m (still) concerned about the lack of a whole register load with “mask” type hint.  I think leaving it out damages the clarity of support for micro-architectural redistribution, which is critical for wide SIMD.
• If we really will not add the instruction, I’m thinking there’s a relatively simple sequence that does the job, like save vl, set it to max, do an ordinary mask load, restore vl.  Could you add that sequence somewhere.  Maybe in the note about not having the mask version.  That would help make the completeness of support clear for micro-architectural redistribution.
2. In Section 3.5, I’m not sure why vlenb must be a design-time constant.  An implementation could vary it as a mode.  So, I think the wording should allow that.
3. Section 13.19 has a typo.  It says “widening” when I think it means “narrowing.”
4. In Section 14, what is the thinking on why there’s no update of the destination of reductions when vl=0?  I can’t see any reason not to update – it seems easier to update – and it could, in some circumstances matter.  This rule means that code has to ensure that it does not execute a reduction in a rare case that vl might be zero unless the source scalar and destination scalar are the same register.  Why require that?
5. In Section 7.8, I thought we wanted the set of registers a segment load/store could access to be limited to an aligned group of eight to allow optimizations on the renaming of registers.  So a three register group could start at register #3, for example.  But here it says that a sequence can start anywhere.

    Bill