On 6/15/20 6:54 PM, Andrew Waterman wrote: Intra-procedure spills were my first concern. I assume "callee-save code" means the code that saves callee-save registers before using them and restores

I guess the main use case is intra-procedure spills, since callee-save code and context-switch code can’t know the previous tag? If the main use case is intra-procedure spills and caller-saved

Hi Bill, My understanding was that the whole register loads and stores work by reinterpreting the (VLEN) bits in a V-register as if SEW were 8; in particular, any bit-permutation induced by vs1r.v

The whole register loads and stores in section 7.9 of the spec are currently specified as having an element size of 8-bits. Could they be extended to cover all sizes instead of just the 8-bit size?

I've not seen very many responses here. I'll try to describe more precisely what's concerning me. In a wide, in-order SIMD core, I can expect two VLEN sized memory accesses per cycle. So a

Does the index of b[i] for a[ ] might be invalid in "SPEC CPU 2006" test?

Hi all, In this page I would like to discuss about fault-only-first indexed load instructions since we have certain using cases, for example, SPEC CPU 2006 4.1.bzip2 src/blocksort.c:line 712. For

Hi Krste, I've been thinking about what happens with this proposal and whole register loads and stores - under the assumption of adding uops (out-of-order or in-order) when a micro-architectural

I agree that this should be default or base configuration. I believe the extended fractional layout is a 6th approach. Issue 465. Does it qualify as a known option? As with option 2 load and stores

TL;DR: I'm leaning towards mandating SLEN=VLEN layout, at least for application processor profiles. Regarding register layout, I thought it would be good to lay out the landscape and comparison with

I finally pushed minutes of last meeting (attached) Our next meeting is later today (Friday Jun 12) with details available on task group calendar. I’m preparing a note on vector register layout,

I think that it's important that SLEN=VLEN is the extension. For the same reason that TSO memory ordering is the extension and RVWMO is the default. Or even M is the extension rather than not-M

There hasn't been any traffic on this feed about  vector layout, and specifically about v0.9 SLEN size standards.     So I will add my thoughts here with the hopes that I will not take excessive

Now I can add AsciiDoc and KramDoc artifacts to those HTML and PDF artifacts :-( [Andrew Waterman]: We have tagged version 0.9 on github,

Hi, Jiejie, Thank you for the work. We are going to use these intrinsics function to optimize BLAS level 1&2 kernels on OpenBLAS RISC-V branch ( https://github.com/xianyi/OpenBLAS/tree/risc-v

The v0.7.1 rvv spec is a draft of a proposal, and has no official status. There are no plans to support it in the upstream GNU toolchain. Support for it was added to qemu, but the current plans are

Hi all, A few days ago, we have put the vector development kit (including prebuild compiler, QEMU simulator, Linux image, user manuals, etc.) on the github[0]. Many community friends have reported

Hi Kai, There is a little issue for function lists, How to compatibility with multiple RISCV vector standards ? AFAK，the riscv vector 0.7.1 is stable version like long term version of Linux

Hi all, We could move the discussions about RVV intrinsics here: https://github.com/riscv/rvv-intrinsic-doc. Thanks. Kai

On 2020-05-29 8:21 a.m., Roger Espasa wrote: I'm not sure how to interpret this table (been puzzling over it). But I believe the LMUL>1 case for v0.9 is incorrect for the same