I've updated the proposal to describe the corner cases: https://github.com/riscv/riscv-v-spec/blob/vfrecip/v-spec.adoc#149-vector-floating-point-reciprocal-estimate-instruction

We’ll have our regular TG meeting in a few hours per member calendar. We’ll continue to clean up remaining issues for v1.0, Krste

For the code segment given, Blelloch's loop raking approach would be worth exploring for the V extension. This approach involves large constant stride accesses to A[] and col[j] array but will keep

I messed up the links: the list of open unlabeled issues is here: https://github.com/riscv/riscv-v-spec/issues?q=is%3Aissue+is%3Aopen+no%3Alabel On 2020-07-09 6:28 p.m.,

There are 19 open issues that aren't yet labeled. Does it make sense that those who will be on the call review them with an idea to categorize as for or after V1.0? That should also

here is dongarra’s take on HPCG. hope this helps. —————————— I believe that the (rough) idea I sketched earlier in this thread (May 8) still works with the latest version

I'm following up with detailed semantics in the form of a self-contained C++ program. The `recip` and `rsqrt` functions model the proposed instructions. When the program is invoked with the

I believe that the (rough) idea I sketched earlier in this thread (May 8) still works with the latest version of the spec --- please correct me if I'm wrong --- what I called "sketchy type-punning"

Hi Krste, Just would like to continue Roger's question on hardware implementation, as you said it can be done with a parallel-prefix-style OR-reduction tree, so can you please explain how we can avoid

please share the asm for spmv, the key kernel (s), in any case, the execution time for operations using a mask, is very implementation/machine dependent it is a function on how aggressive, in

| I am now investigating how to efficiently implement sparse matrix X (dense) vector multiplications (spMV) using RISCV vectors using bit-vector format of | compressing the sparse matrix. The inner

vmhash should be cheap relative to the work you're doing on each loop. redoing vmhash in each stripmine could lead to better performance as you find longer non-conflicting index runs, rather than

Hi Krste, I read through your code and thanks for correcting my errors, 'or' is a good idea for multiple duplicates. Here I'd like to explain why I made things a bit more complicated in my code. In

Date: 2020/7/03 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~6 Current issues on github: https://github.com/riscv/riscv-v-spec This call was

I realize it is a holiday in US today, but I will hold a vector TG meeting for those who can attend in usual slot as given in member calendar. I've been updating the spec with earlier decisions, and

| On 2020-07-02 8:20 p.m., Krste Asanovic wrote: || I added a note on this issue to spec: || || NOTE: When migrating a software thread between two harts with || different microarchitectures, the

I appreciate you not punting this to "profiles" However, isn't this "mutually supported" effectively a profile constraint or consideration? Should we therefore include in the note that the specifics

I added a note on this issue to spec: NOTE: When migrating a software thread between two harts with different microarchitectures, the `vstart` value might not be supported by the new hart

I trust this is not just noise. A laundry list of concerns Assess objectives and those met as we approach v1.0 of RVV Polymorphism has not

TL;DR; I make clarifications on meeting minutes. I propose we present   1) a relaxed RVV memory/process model, more relaxed than we believe current implementations require for optimal