Re: Smaller embedded version of the Vector extension


Zalman Stern
 

If the minimum VLEN is at least 128-bits, one can translate NEON/SSE intrinsics directly without having to have every vector instruction dominated by a loop over the vector length.

-Z-


On Thu, Jun 3, 2021 at 9:38 AM Guy Lemieux <guy.lemieux@...> wrote:
Krste, to be clear,The issue



On Thu, Jun 3, 2021 at 9:24 AM Krste Asanovic <krste@...> wrote:
> > On Jun 3, 2021, at 9:16 AM, Guy Lemieux <guy.lemieux@...> wrote:
> >
> > 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 improve software portability
>
> This is the requirement for app processors, which are not generally small cores.
> Most competing SIMD extensions are at least 128b per vector register.


The RVV spec should be inclusive, rather than exclusive. Setting VLEN
>= 128 is a higher threshold that makes it less inclusive.


> > 4) are there any disadvantages to VLEN >= 64 (versus the current VLEN
> >> = 128)? (I can't see any)
>
> Lower performance on codes that work well on other app architectures.

Sorry I wasn't clear. Of course, an implementation with VLEN=64 would
likely be slower than one with VLEN=128.

To clarify: are there any disadvantages to allowing VLEN=64 in the
spec as a minimum threshold?

Software should be agnostic of VLEN, but the truth is programmers will
squeeze out every last bit where they can and they will latch on to
this minimum value when doing things like re-using LSBs of pointers,
setting minimum chunk sizes, etc. Hence, asking them to expect VLEN=64
as a minimum would be better (more inclusive).

I can't see how this would hurt performance.

Guy





Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.