On Thu, May 7, 2020 at 10:47 AM Guy Lemieux via lists.riscv.org <glemieux=vectorblox.com@...> wrote:

can you perhaps explain how the vector operands are to be used/allocated?

ie, it appears you wish to use the type

system to name vector registers, but there is no limit on these so there must be some implicit register allocation and behaviour when running out.

sorry I wasn’t clear.

the data types, eg vint64m1_t, are for data elements.

all of the example API definitions also use these same element data types as arguments, but they should be using a data type corresponding of to a vector of elements.

the example code (sgemm, saxpy) uses pointers to these data elements as the vector data types, where the underlying memory has been previously allocated somehow. these examples are flawed and need to show how to connect sequences of vector compute instructions together in a way that does not force every vector result vd to be written back to memory. 

the ability to create and use pointers to vectors of elements, and to individual elements, makes the process of compilation harder. it has to detect all of these accesses and insert vector stores or insert vector element extract instructions because of pointer dereferences. yet, this code doesn’t even use the suggested vector element data types, so it will be a challenge if not impossible for the compiler.

instead, vectors should be allocated as an abstract entity that requires accessor methods to set/get individual elements.

without this, every vector compute instruction is going to need to do two vector loads before and one vector store after execution of the vector operation. 

this is related to issue #17. the array style is most natural. the size of the array should not be a parameter, it should be the size of the entire physical register (?LMUL*VLMAX bytes?)