Hi @asmorkalov, thank you for your review and I am going to explain the design of this patch in detail about your review comment.

I agree that calling malloc for each vector variable is expensive and may fragment the heap.

The reason I did this is to get a vector variable *pval in struct in order to remove unnecessary intrinsic functions for loading array and storing vector.

Normally, for a vector variable, we would try to declare it with intrinsic type directly. But we can not declare a RVV intrinsic vector type like vuint8m1_t val in the struct because it is sizeless and the compiler doesn't know how many bits did it needed on the stack. However, in OpenCV UI, we know exactly how much bit is needed, 128.

So I tried an scalar array and a RVV type pointer like below (but not a RVV type array like vuint8m1_t[nlanes*8], we may NOT need an array containing vector) , in this way, *pval is the vector variable that we want:

float val[nlanes];
vfloat32m1_t* pval = (vfloat32m1_t*)val;

it's work but generate unecessay store instructions. And I find that use the malloc way like below can eliminate unecessay instructions, same as the array way, *pval is the vector variable that we want:

vfloat32m1_t* pval = (vfloat32m1_t*)malloc(nlanes*32);
~v_float32x4() {free(pval);}

it also works as well as more concise assembly. And most importantly, although we call malloc in the source code, no malloc is actually called in assembly with the help of compiler optimization because (I guess) the parameters of the malloc function is a constant (128). But in more complex cases, the compiler may not be able to optimize.

https://godbolt.org/z/8sa6W8vf3 shows the difference between using a scalar array and using malloc.

Therefore, there is a tradeoff between more unnecessary store instructions (by using array) and possible malloc calls, what's your opinion?

And I would like to try to explain why I think this does not cause a memory leak:

Firstly, if there is no malloc called in assembly, then no memory in heap is created, also no way to leak.
Secondly, assuming there is a malloc called. In this case, we always operate as *pval and do not operate pval directly, which means we may change the value pointed by the pointer, but does not change the pointer itself. In other words, the pointer pval always points to the memory from malloc, and will be free in the destructor.

So there does not seem to be a memory leak, please correct me if I am wrong.

Even if compiler is smart enough and does not generate real malloc calls in some cases, it's bad idea to drop pointer values and replace them with the new one. It bad logic and it stops working. Also, it's unsafe to call free for the cases like this:

        short v[] = {v0, v1, v2, v3, v4, v5, v6, v7};
        *pval = vle16_v_i16m1(v, nlanes);

The pval points to stack frame, but not to buffer on heap. And it's good luck again, that compiler helps you with UB.

Tested with qemu64 and clang version 14.0.0 (https://github.com/llvm/llvm-project.git f5f0bd8e3d972d040827c88adf1a9880ebcb821e). Also I have to tune toolchain file and replace hardware configuration with -march=rv64gcv1p0.