About

Basic functionality is complete and we have moved focus performance evaluation/improvement  of the vectorizer and identifying gaps. 

1. Given the generic vectorizer implementation and V extension capabilities, are we vectorizing the loops we should?
2. Are we avoiding vectorizing loops we should not due to profitability concerns?
3. Are we exploiting vector length agnostic approaches or falling back to static vector lenghts?
4. When we vectorize, do we do so efficiently?

Vector implementations of key library routines such as mem*, str*, vector math (sqrt, sin, cos, etc) are primarily an issue for core libraries such as glibc.  But coordination is needed between glibc and GCC to utilize libmvec (for example).

Stakeholders/Partners

RISE:

Ventana:  Robin Dapp (full time) + Jeff Law for oversight/review

Rivos: Palmer Dabbelt for oversight/review

           Joern Renneke (Embecosm contractor for Rivos): Some initial vector math library implementations, compiler expansion of memcpy

SiFive: Kito Cheng for oversight/Review role

External:

RiVAI: Much of the initial work was done by Juzhe.  This has included the basic design/implementation, ABI work, etc.  Juzhe continues to play a major role in design/implementation going forward.

SuSE/ARM/Linaro: Some of the work in this space has touched on generic parts of GCC.  Various engineers from Suse, IBM, ARM & Linaro have been involved on an as-needed basis.  Richard Sandiford, Richard Biener and others.

Dependencies

The most pressing upstream dependencies are:

1. PSABI specification for vector argument passing and return values
2. Kernel support to enable discovery of the V extension – starting to see initial downstream uses of these capabilities
3. glibc support for libmvec to enable vector API for key math library functions such as sin, cos, sqrt, etc

Status

Updates

30 Aug 2023 

• Improvement to vectorization spun out as new project