I filled out the RISC-V Policy: Change and Extension Rationale as best I could for the issue #427. I believe it is accessible by all. But I will also paste the contents below. https://lists.riscv.org/

I posted a comment to the closed #427 Not everyone subscribes to GitHub, so I post it below, I am requesting this proposal be reconsidered/re-evaluated for V1.0 inclusion in light of the posting: Some

Now annotated version --detail https://github.com/David-Horner/recip/blob/master/vrecip.cc For the 7x7 below notice the biased value does not exceed 21 for recip (5 of 7 bits) and 15 for rsqrt (4 of 7

This is the link to the revised code that does n by m LUT https://github.com/David-Horner/recip/blob/master/vrecip.cc

What I initially posted was a compilation from days previously, and I pulled in some bogus test results. Here is a fresh run : ./a.out 7 5 ;./a.out 7 6 ;./a.out 7 7 ;./a.out 7 8 ;./a.out 7 9 ;./a.out

This is the program Andrew wrote. https://github.com/riscv/riscv-v-spec/blob/vfrecip/recip.cc That is correct, Andrew's approach assumes the implicit high hidden bit. Andrew chose a range from [xn , (

The error is relative error. The calculation is unchanged from Andrew's original. (Although I explicitly force double even when it shouldn't matter). The test range is from 0.5 to 1 inclusive. Again I

The current LUT generator assumes N-by-N look up table. I will load in my github Andrew's program modified to take input (index size) and output (estimate number of bits) arguments. (--verilog still g

To be clear, this is SEW/LMUL ratio change, correct? All other values being valid and the "SEW and LMUL" combination itself being valid. Providing an invalid SEW and LMUL combination will set vill for

this is in the x0,x0 case? I see this as the only case that needs to be considered. The EE does not have to both set vill and establish a saved vl value in the same instruction. A sequence of vsetvl i

Not a hill for me to die on, but I believe vsetvli x0,x0 is sufficiently important that even this aspect should be fully vetted. Other vsetvl[i] instructions are essentially different beasts than this

In my response to your prior post I stated that #1 and #3 are needed to guarantee vl invariance in speculative cases. I agree with you that such a guarantee is not needed, as assumption is adequate to

see the rest of the thread for more context. To clarify for the list: The RAW (Read after Write) hazard already exists for all vl consumers, specifically all RVV data operations and vl csr read. PoR r

Messed up when I was trying to simplify the text.

TL;DR; Point of agreement #1 - x0,x0 variant should not change vl. I believe we are also in agreement on #2 - if vl would change because of a SEW/LMUL change vill should be set. Outstanding questions:

I wholeheartedly agree with resolving on the mailing list. This should be the rule not exception. My considerations for allowing vl to change were a) having a compelling reason to change PoR. vsetvl[i

This was on Github; as not every one subscribes and it will be considered at TG, I include it on this list. First Krste’s synopsys, then my (modified) Github reply, then my thoughts for the TG and las

Excellent observation. at least 1 bits better. and when r*x close to 1, much better.

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

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 determine those th