Date: 2020/3/6 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~21 Current issues on github: https://github.com/riscv/riscv-v-spec Note, the Zoom meeting details have changed.

Date: 2020/2/21 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~13 Current issues on github: https://github.com/riscv/riscv-v-spec Note, the Zoom meeting details have

Hi all, we have updated to version 0.8 of V-ext our LLVM-based experimental compiler and the intrinsics reference. EPI builtins and examples:

I left the encoding unspecified in the proposal. That was intentional as I saw various tradeoffs. However, I now recommend the codes be in order of increasing VLMAX value as so:

Special lmul code in vsetvl{i} to derive LML from existing SEW/LMUL and provided sew code. As mentioned in the TG we suggested widen LMUL to 3 bits with 7 (explicit) states.

I added the change to add a vcsr including FP fields (this came out much cleaner I think) - please check over. Another minor change was to fold in the suggestion to move VS to a two-bit wide gap

I'm realizing the idea doesn't quite work unless machine actually stores the fractional LMUL value (to cope with SLEN and widening instruction behavior), and so would need the new instruction and

Could a fractional LMUL circumvent the constraint that a widening instruction's output register group must be larger than its input register group(s)? --Nick Knight

In the last meeting, we discussed a problem that would be introduced if we were to drop the fixed-size (b/h/w) variants of the vector load/stores and only have the SEW-size (e) variants. From

Date: 2020/1/24 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~20 github: https://github.com/riscv/riscv-v-spec Outstanding items from prior meeting: #362/#354, #341,

Oops, yes, I meant vslide1down. Using vslide1down isn't about performance; it's the only way I know of for the debugger to construct a vector without additional storage. The alternative would have

I'm curious why you chose to be symmetrical (no need), and why you decided incrementing for slideup decrementing for slidedn (I would do the opposite). By incrementing for vslidedown, and

Thanks Guy for the explanation, but my implementation is both incrementing element index for slideup and decrementing element index for slidedown (which is symmetrical implementation and simplest from

Hi Thang, I think Andrew is suggesting that the vslideup restriction is there to allow some flexibility with implementations. However, one of (vslideup/vslidedown) needs to allow the same source/dest

Hi Andrew, I do not understand your statement. Why is it important? Why is the difference with slideup? The slideup cannot clobber the source operand with destination operand because the

It's important that the slidedown instruction can overwrite its source operand. Debuggers will use this feature to populate a vector register in-place without clobbering other architectural state.

The slideup instruction has this restriction: The destination vector register group for vslideup cannot overlap the source vector register group or the mask register, otherwise an illegal instruction

Oh, heck [*]: Callee saved registers of any form can have bad performance where there is a potential partial register issue. E.g. on an out of order machine with register renaming. Although even

Providing callee-saved vector registers in the regular C calling convention might actually degrade performance, as most vector computation is done in leaf functions or in strip-mine loops that don't