My take is the same as Andrew has outlined below. Bill On 10/15/20 4:30 PM, andrew@... wrote:

Yep, it's sufficient for the needs of while loop Vectorization. It is suboptimal for "SIMT on vector". For that you need a completion mask. and it is far too late to add that to the

Forwarding this to tech-vector-ext; couple comments below. Indeed, I've found other microarchitectural reasons to favor this approach (e.g., speculating through mask-register values). Enumerating all

Per calendar instructions, in usual time slot, Proposed agenda: #560 vmulh rounding mode #576 vlsegff exception behavior #550 names/contents of initial vector subsets #568 disabling/context swtiching

Vector Extension Task Group Meeting When: Friday, 12 June 2020 8:00am to 9:00am (UTC-07:00) America/Los Angeles Repeats: Weekly on Friday, through Thursday, 8 October 2020 Organizer: Krste

Done. Thanks Roger. From: Roger Espasa <roger.espasa@...> Date: Sunday, October 4, 2020 at 12:49 PM To: Joseph Rahmeh <Joseph.Rahmeh@...> Cc: "tech-vector-ext@..." <tech-vector-ext@...>, Robert

Joseph, May I suggest you open a git issue here: https://github.com/riscv/riscv-v-spec/issues with these two questions? It will help better tracking and will ensure whatever the resolution is, it does

Should vid.v raise an illegal instruction exception when masked and when the destination group overlaps v0 ? Should vid.v raise an illegal instruction exception when vstart > 0 ?

Krste

I will add my thoughts related to "embedded" imprecise: Why embedded specifically? Linux handles GPUs as coprocessors. My understanding is that by their nature, the internal state

Is there already a doc/issue specific to this imprecise handling that we can reference before and during the meeting?

Reminder we’ll be meeting tomorrow in usual slot. I’d like to spend the time discussing imprecise trap handling for embedded vector systems. Hopefully, we can all see the new correct link on

Never say never. Appears to be the mantra for V extension. Yes, the intent is that the V specification mandates LMUL of 8, 4 and 1. Even for minimal systems of VLEN=128; not only for

Hi Joseph, Thanks for the clarification. The wording in the spec is admittedly vague: "LMUL can have integer values 1,2,4,8.", etc. My understanding of the intent is that all implementations must

Hi Nick, Thanks for the reply. I was not asking for non-power of 2 LMUL. I was asking about LMUL values not supported by some implementation. Let’s say that for SEW=128, an implementation

Sorry, in case it wasn't clear: typo it's not too much of a burden.

Hi Joseph, Thanks for your comments. I apologize, but I don't fully understand your proposal, or the problem it solves. To help explain my confusion, here are two thoughts. The supported LMUL (and

In the latest vector proposal (draft of version 1.0), there is the following restriction on widening instructions (section 11.2) For all widening instructions, the destination EEW and EMUL values

I am in favour of effectively weakening the scalar/vector vector/scalar load/load order requirement. However, this cannot be performed in isolation  without regard to the rest of the RVWMO

Date: 2020/9/25 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~14 Current issues on github: https://github.com/riscv/riscv-v-spec Issues