I agree with Krste's support for Guy's proposal here. Loops with multiple element widths are likely to have more non-vl-changing instructions than vl-changing instructions. Knowing this from the

The main issue is whether the current PoR has any useful purpose when vl changes. I don't subscribe to "field of dreams" approach. I tried to find some scenarios hoping there would be some useful

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

I want to bring this to group's attention as I think I've convinced myself that Guy's suggestion is the correct path to follow, i.e., vsetvli x0, x0, imm will raise vill if the new SEW'/LMUL'

Hi, Sorry the picture was dropped somehow, here I can present using pure text: For the simple loop example: for (i = 0; i < N; i++) { a[b[i]] = a[c[i]] + 1; } We can use the algorithm: while (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,

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

I managed to swap the file names around, and sent earlier week's minutes instead of last week's. Here's the correct minutes from last week (also fixed in repo). Krste Date: 2020/7/10 Task Group:

A belated posting of minutes from last week's meeting. We'll be meeting again today as per member calendar, Krste Date: 2020/7/03 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger

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

Yes.

Do we improve accuracy a bit if the step is: t = 1.0 - r*x; x = x + t*x instead of: t = 2.0 - r*x; x = t*x Bill On 7/14/20 2:58 PM, Bill Huffman wrote:

On 7/14/20 2:54 PM, Andrew Waterman wrote: Sorry, I had scalar on the mind.... Bill

Actually, none of the vector instructions use the rs3 field (the vector FMAs are destructive to save encoding space). There are still several R-type code points left in the vector opcode, but it has

On 7/14/20 2:30 PM, Andrew Waterman wrote: Seems like they shouldn't be so big as they don't specify rs3 at all. Are we tight on two register input opcodes? Bill

FWIW, one of my concerns with adding the "step" instructions is opcode space, since we are already very tight. I suppose a compromise might be to make them destructive. This would have no perf.

I forgot to mention that I added sample vector code for estimating square root: https://github.com/riscv/riscv-v-spec/blob/vfrecip/vector-examples.adoc#square-root-approximation-example Handling the

Hi Andrew et al, Thank you for sending the code. I am attaching an updated version of recip.cc, implementing the complete Newton-Raphson sequence, using the proposed reciprocal estimate instructions

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