should intrinsic support mask operation without masked off (merge) parameter?

[riscv-non-isa]

should intrinsic support mask operation without masked off (merge) parameter?

[Hsiangkai]

I describe the issue in https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#mask-in-intrinsics.

I follow the suggestions provided by @rdolbeau to provide "zero" and "don't care" semantics through "merge in output" intrinsics.
I follow the suggestions provided by @ebahapo and @zakk0610 to encode mask in suffix.

Any suggestions?

[ebahapo]

I agree that the suggestion to specify how the mask works as a suffix is clear enough, while avoiding being verbose.

[rdolbeau]

I think it all depends on the underlying semantic. SVE has this extra suffix (of which I'm not a fan) mentioned by @zakk0610 where _z and _m are hardware function, and _x is semantic.

If I understand correctly, V only has 'merge in output' semantic, so to me it would seem logical to have just the one masked variant, such as vadd_vv_mask_x_i8m1, but with all three operands specified: merged output, and both inputs. Then for the other two useful cases, the explicitely merged output would be set by a register-defining intrinsic:

vint8m1_t vadd_vvv_mask_x_i8m1 (vint8m1_t merged, vbool8_t mask, vint8m1_t op1, vint8m1_t op2);

and with some use cases:

vint8m1_t r1 = vadd_vvv_mask_x_i8m1(d, m, a, b); // merge semantic into 'd'
vint8m1_t r2 = vadd_vvv_mask_x_i8m1(vzero_v_i8m1(), m, a, b); // zero semantic implemented by merge
vint8m1_t r2 = vadd_vvv_mask_x_i8m1(vundefined_v_i8m1(), m, a, b); // don't care semantic implemented by merge

Then the compiler's register allocation & associated passes can do what's necessary to optimize the code, and what happens is clear to the user.

... of course it requires some register-initialization intrinsics, ''vzero_v_i8m1()" and "vundefined_v_i8m1()" should be self-explanatory.

Cordially,

[edit: added a third 'v' in my examples, as we have three parameters ?]
[edit2: typos]

[zakk0610]

I assume all we had agreed that the function naming is asm 1-1 mapping.
so there is only two 'v' because the asm op is vadd.vv.

[zakk0610]

I think it all depends on the underlying semantic. SVE has this extra suffix (of which I'm not a fan) mentioned by @zakk0610 where _z and _m are hardware function, and _x is semantic.

If I understand correctly, V only has 'merge in output' semantic, so to me it would seem logical to have just the one masked variant, such as vadd_vv_mask_x_i8m1, but with all three operands specified: merged output, and both inputs. Then for the other two useful cases, the explicitely merged output would be set by a register-defining intrinsic:

Yes, V only has 'merge in output' semantic.

vint8m1_t vadd_vvv_mask_x_i8m1 (vint8m1_t merged, vbool8_t mask, vint8m1_t op1, vint8m1_t op2);

and with some use cases:

vint8m1_t r1 = vadd_vvv_mask_x_i8m1(d, m, a, b); // merge semantic into 'd'
vint8m1_t r2 = vadd_vvv_mask_x_i8m1(vzero_v_i8m1(), m, a, b); // zero semantic implemented by merge
vint8m1_t r2 = vadd_vvv_mask_x_i8m1(vundefined_v_i8m1(), m, a, b); // don't care semantic implemented by merge

good idea. +1
I think supporting merge semantic with additional help init function is enough.

BTW, if we decide to encode mask in abbreviation (_m) into function name,
I think put it in function suffix would be better and clear.

@rdolbeau
do you have strong feelings regarding the precise order of operands?
SiFive's proposal the operand order is "vbinop(mask, merge, lhs, rhs)", it looks closer to "!mask ? merge : binop(lhs, rhs)", it different to EPI's.

Then the compiler's register allocation & associated passes can do what's necessary to optimize the code, and what happens is clear to the user.

... of course it requires some register-initialization intrinsics, ''vzero_v_i8m1()" and "vundefined_v_i8m1()" should be self-explanatory.

Cordially,

[edit: added a third 'v' in my examples, as we have three parameters ?]
[edit2: typos]

[rdolbeau]

a) yes, only two v to match the ASM, I shouldn't have second-guessed myself

b) to me masking is part of the semantic and operands so I would put it before the return type, but at the end works too...

c) regarding the order: no preferences, just that it should be homogeneous , as usual :-)