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

i have not been following this thread in lots of detail could someone please explain why we need to differentiate between ordered and unordered load/stores. in the 6 or vector systems i have been

Guy Lemieux commented: Maybe what's below could be improved by saying that if the base address (in src1) was non-idempotent or an "ordered channel," the entire instruction would run in order. If

I think from this morning, we are considering: Ordered scatters are done truly in order Strided stores that overlap (including segmented ones) will trap as illegal All other vector loads and stores do

Though I don’t know if we’re affected by calendar changes, Krste

Andrew, Nick, Thank you for the quick responses. Nick, the text updates look like they directly reflect the intent. -Cohen