There is similar CV_ALWAYS_INLINE macro in cvdef.h

Is it possible to reduce size of this macro? Or even omit it?

I don't see how to omit it. Suggestions?

Documentation for v_reduce support matrix is here.

if you want to use them in OpenCV algorithms code, then corresponding documentation and intrinsic tests should be updated too.

Updated.

Please use this form: j <= len0 - _uint16x8::nlanes (used in many vectorized loops)

64-bit floats are not supported too.

Why do we need x4 unrolling?

It makes it a lot easier to handle the 'mask' case down below (v_load_expand_q is really bad on some platforms).

This loop doesn't work this mask.

Perhaps, loop below can be iterated over loaded mask size:

-4 * v_float64x2::nlanes
+v_uint16x8::nlanes

with corresponding comment near "for" that loop iterations are performed over mask values.

I'd rather keep it the way it is for consistency with the other cases.

IMO template or macro is redundant here. If there was an opportunity to use something like v_reinterpret_as_vectype<uchar> instead of v_reinterpret_as_u8 I would prefer template as a more debug friendly alternative. But at the moment it is impossible, so the macro looks like the only option. Also macro parameters could be reduced to suffix2, VT, IT, T. Something like that:

#define MINMAXIDX_REDUCE(suffix2, VT, IT, T) \
CV_ALWAYS_INLINE void minMaxIdx_reduce( VT &valMin, VT &valMax, IT &idxMin, IT &idxMax, IT &none, \
                                        T &minVal, T &maxVal, size_t &minIdx, size_t &maxIdx, \
                                        size_t delta ) \
{ \
    if ( v_check_any(idxMin != none) ) \
    { \
        minVal = v_reduce_min(valMin); \
        minIdx = (size_t)v_reduce_min(v_select(v_reinterpret_as_##suffix2(v_setall((VT::lane_type)minVal) == valMin), \
                     idxMin, v_setall_##suffix2((IT::lane_type)-1))) + delta; \
    } \
    if ( v_check_any(idxMax != none) ) \
    { \
        maxVal = v_reduce_max(valMax); \
        maxIdx = (size_t)v_reduce_min(v_select(v_reinterpret_as_##suffix2(v_setall((VT::lane_type)maxVal) == valMax), \
                     idxMax, v_setall_##suffix2((IT::lane_type)-1))) + delta; \
    } \
}

This is not the same - some types (float and double) do NOT use max as -1

As far as I could understand this value is used as "do not select" value, to restrict result of the following v_reduce_min to indexes of valid search results only. So I don't see the reason that denies replacement of this value by greater one.
Could you please share your thoughts on this?

This code is used to create a position location of the min or max that can never occur. Your code could be creating NANs for non-integer types. Use of NANs can be unpredictable.

Position location types are unsigned integers of different width for all existing instantiations. I doubt that floating point types could be used for that somewhere in the future but anyway such a change will require update of the whole algorithm since idxMax still could contain not yet updated parts of the initial none value which also should be treated as NaN's in that case

I think there should be cast to int rather than to LaneType to avoid overflow

I mean v_reduce_sum only. It's fine to have LaneType for other reductions since they return value is already of LaneType

IMO it would be better to extend the overall set of intrinsics

I think until the intrinsics for all the platforms use v_float64x2 and v_uint64x2 more fully, this is a better approach.