@asmorkalov I believe this PR is simple and doesn’t introduce any issues. Could you review and merge it quickly? I have several other PRs waiting on this one. Thanks a lot!

Did you consider using overloaded intrinsics variants where possible? Sections 6.4 - 6.6 and Appendices C and D of the spec.
I'm asking because we are trying to reduce number of complex multiline macros for better readability and debugging support. It would be better to use templated traits classes instead, see examples in #26892 and #26865. If it is not possible, then OK.

I think I have use overloaded intrinsics in all possible places. The helper class in this PR is designed to solve the macro problem, which provides unified interfaces.

The remaining parts in the helper class that use macros instead of overloaded intrinsics are mainly due to the following two reasons:

1. For operations like load and cast, overloaded intrinsics require different function names to distinguish between return values.
2. For many operations, although the meaning is the same, the function names differ based on whether they are signed integers, unsigned integers, or floating-point numbers (e.g., add, addu, fadd).

For the two examples you mentioned, they do exactly the same thing as this PR, and parts of this patch are also inspired by them. They use macros to define the helper class and use the helper class for templates. And this PR is to introduce a unified helper class.

For the two examples you mentioned, they do exactly the same thing as this PR, and parts of this patch are also inspired by them. They use macros to define the helper class and use the helper class for templates.

Those PRs don't use macros, only templates:

template<typename T> struct rvv;

template<> struct rvv<float>
{
    static inline size_t vsetvlmax() { return __riscv_vsetvlmax_e32m4(); }
    static inline size_t vsetvl(size_t a) { return __riscv_vsetvl_e32m4(a); }
    static inline vfloat32m4_t vfmv_v_f(float a, size_t b) { return __riscv_vfmv_v_f_f32m4(a, b); }
    static inline vfloat32m1_t vfmv_s_f(float a, size_t b) { return __riscv_vfmv_s_f_f32m1(a, b); }
    static inline vfloat32m4_t vle(const float* a, size_t b) { return __riscv_vle32_v_f32m4(a, b); }
    static inline vfloat32m4_t vlse(const float* a, ptrdiff_t b, size_t c) { return __riscv_vlse32_v_f32m4(a, b, c); }
    static inline void vse(float* a, vfloat32m4_t b, size_t c) { __riscv_vse32(a, b, c); }
};

Other PRs use macros, yes.
If I understand correctly, the code without macros will become larger, but it might be benefitial for readablility and debugging. And splitting these trait classes into separate ones might make the implementation less complex.
However if it is not possible, then I'm fine with current approach.

Sorry, I didn’t look closely. I thought you were referring to the minmax.hpp in the latter PR (#26865) that I referenced.

If we fully expand those macros, the file would end up being several thousand lines long. Another option is to use inheritance, but even then, it would add nearly a thousand lines. If you think that’s better, I can use inheritance to remove all the macros. Alternatively, if we go with inheritance, perhaps it would be better to split the signed integers, unsigned integers, and floating-point numbers into three separate files?

No, let's leave macros then.

Since each unified function corresponds to a single intrinsic, I believe it’s acceptable to use macros to define these "function aliases." Developers can then use them just like the original intrinsics.

@horror-proton Indeed, in C++11, template specialization can be used for dispatching, but this would result in each function generating an additional three functions each with more than three lines of code. Also, if we don’t use macros, I believe using inheritance for categorization would look better. If macros are used, I think this is the shortest approach for now. As for the functions you mentioned that don't need to worry about VEC_T, first, I believe there's no case where VEC_T is unknown. Second, with the current implementation, it's easy to add a template function to call VEC_T::vmin.

@mshabunin You can merge that PR first. I will resolve conflict and try to make that PR use this PR's helper class.

The related patch has been merged. Please rebase and fix conflicts.

Since the last commit make a great change, I have tested testcases all mentioned in corresponding PR (#26865 #26892 #26958). The list is too long so a file is attached. solve_dxt_pyramids_report.txt

Through some factor <0.9 and >1.1 appears, when rerun these testcases they have similar performance again. So it looks like this commit doesn't break anything.