Great points Ken & Earl. One thing I'll point out is that this does not necessarily have much to do with EDIV specifically. For example, the main goal of EDIV is to support smaller element dot product

The AMX extension for AVX512 is an interesting approach.... https://en.wikichip.org/wiki/intel/dl_boost

To determine the trap cause, without such a bit, software will have to examine many possible vtype settings that are unique for each particular instruction. The trap handler will be highly customized

Ok, this makes the opcodes virtually useless for other instructions. Instead, shouldn't we be setting a bit similar to vill? I realize vill is only set on illegal vset* instructions; in this case it w

That’s great news, thanks Krste! … haha i tried but can’t think of a use case !! I don’t have a strong opinion, but I prefer a route that allows us to recover those instruction encodings — they seem t

Hi, The way 18.1 and 18.2 currently read in the V spec is a bit confusing. It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor". 1) Pr

I’ve taken a stab at reducing the number of instructions in my RVV-lite proposal. The overriding goal, in my mind, is to preserve forward software compatibility so the ecosystem doesn’t need to fragme

thanks, I see the api comments now too. pretty easy to do using vslide1up/dn and vmerge g

for zip, you don’t need to use vrgather. instead, use vector widening (eg vwaddu with x0) to double the element size (ensuring the MSBs are 0) for one half of the set. apply vslide1up and widening to

that's pretty handy, actually. I'm not sure it should be a property of the V spec itself, rather it could be a requirement that software which is translated in this method could require an implementat

Krste, to be clear,The issue The RVV spec should be inclusive, rather than exclusive. Setting VLEN Sorry I wasn't clear. Of course, an implementation with VLEN=64 would likely be slower than one with

What is the advantage to RVV requiring VLEN >= 128? I think this should be changed to VLEN >= 64 because: 1) VLEN = 64 is more likely for small implementations; creating a mandatory expectation to imp

I think the concern here is lack of a clearly defined data layout pattern for such cases. eg, should the LSBs be in the odd or even register half, or should it be implementation-defined? Guy

For widening and narrowing instructions to work, the V spec depends upon changing SEW (to EEW) and LMUL (to EMUL), such that EEW/EMUL == SEW/LMUL. That is, to change the element size (widen or narrow)

Allowing VLEN<128 would allow for smaller vector register files, bit it would also result in a profile that is not forward-compatible with the V spec. This would produce another fracture the software

yeeesh glad i don’t have to stare at that code too long. i know it’s not your code ... i think it could use a abs followed by a max reduction, then do the rest as scalar ops? these macros appear to be

It depends -- exactly what do you plan to do after determining if a mask is all-0 or all-1 or other? vpopc and vfirst can both special-case these common results via precomputation, so they both take m

Hi, I’m starting a project where we want to use vector intrinsics and generate both 64b and 32b code (for RV64 and RV32). It looks line the best way to do this right now is with GCC, where we were abl

in terms of overlap with that case — that case normally selects maximally sized AVL. the implied goals there are to make best use of vector register capacity and throughput. l i’m suggesting a case wh

I agree with you. I had suggested the mapping of 00000 to an implementation-defined value (chosen by the CPU architect). For some architectures, this may be 16, for others it may be 32, or even 2. The