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 seems to require either that stores are

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

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

These issues discuss the need for order and reasons to have variants: https://github.com/riscv/riscv-v-spec/issues/501 Unordered Indexed Load

Just a quick note here, if Ztso is active then "truly in order" has global ordering too. Much of the discussion was driven by consideration for the difficulty in runtime overlap

I tentatively agree *if* "truly in order" means "as if writes were the equivalent scalar writes of the register elements processed in order from 0 to vl" . However, RVWMO

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

Thanks Krste, that makes sense but the logic is not that straight forward, people usually needs "decompress" when they are using "compress", maybe we can add some comment on this at the "vcompress"

If the decompress is the inverse of compress, then there will be a packed vector holding the non-zero elements and a bit mask indicating which elements should receive the elements after unpacking

Hi all, For common AI workloads such as DNNs, data communications between network layers introduce huge pressure on capacity and bandwidth of the memory hierarchy. For instance, dynamic large

Correct, Krste

Hi all, I understand the EEW, as explicitly encoded in the load/store instructions applies to the vector of indices for the indexed loads and stores. For instance we can load a vector "SEW=8,LMUL=1"

Hi Cohen, Thanks for your careful reading. Hopefully this edit clarifies some of the ambiguity: https://github.com/riscv/riscv-v-spec/pull/565 Best, Nick Knight