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

attached is what we did at convex and it worked quite well. worked well in the context of compiler generated code for stencils and for runtimers like convolution and correlation i am not sure this

I believe I added the correct zoom info on the correct new calendar for tomorrow’s vector task group meeting. Please check and advise if you’re not seeing it, Krste

Ahead of the vector meeting I would like to see if we can address or at least get direction on some of the flagged for pre-v1.0 resolution. There are 3 related flagged issues

i agree with your comment i got this paper from someone who applied their assessment to risc-v vectors http://bsc.es/disclaimer

They mention RISC-V vectors in the intro, but on a quick scan, the results are very ARM-specific, with no real implication for RISC-V vectors. They're pointing out a problem with ARM SVE where

i was made aware of this paper. risc-v vectors are mentioned. one of the key conclusions are (from the abstract) Our experimentsshow that VLA code reaches about 90% of the performance

Reminder there’s no vector TG meeting tomorrow (I have a conflict). We’ll be meeting again on Friday Sep 18 (I’ll work with Stephano to figure out new calendar scheme), Krste

In less concerned with making the FIFO example work, and more concerned with ensuring programs are fully portable across all implementations. Programmers don’t tend to read ISA specs and details.

The problem is not that you have to ensure previous (in the scalar loop order sense) entries don't trap before you take the exception on the later one. The problem is that you have to not complete a

You don't have to ensure previous stores (or loads) have completed - I misspoke. You have to ensure that they don't trap, which might be a much easier proposition. Implementations may typically do

On 9/8/20 1:47 PM, Allen Baum wrote: From most points of view it's a fine method (delay exception reporting until all accesses from logically previous addresses are complete and override). But it

If the memory ordering (in this case specifically memory access ordering, I think - correct me if I'm wrong) doesn't affect the final processor state (which would not be the case for a vector reduce

On 9/4/20 10:25 PM, David Horner wrote: Yes, that's what I intended. Bill

what are the use cases? do we have examples in mind when they would/could be used? are there examples of what developers would want from previous efforts on vector machines? can we write them

Bill, great lists. can we start building a testcase list for these situations and others? maybe a github doc? i am sure these will be documented but I don't want to lose bullet lists like this and

On 2020-09-04 5:00 p.m., swallach wrote: These issues discuss the need for order and reasons to have variants: https://github.com/riscv/riscv-v-spec/issues/501 Unordered

On 2020-09-04 5:53 p.m., Andrew Waterman wrote: Just a quick note here, if Ztso is active then "truly in order" has global ordering too. Much of the discussion was driven

On 2020-09-04 1:18 p.m., Bill Huffman wrote: I tentatively agree *if* "truly in order" means "as if writes were the equivalent scalar writes of the register

This is not terribly straightforward. I'll assume that the trap would only be a function of the stride and element/segment width, rather than checking that two active elements actually overlap at