[Naming] Remove postfix `_m` for merge and compress intrinsic functions.

[riscv-non-isa]

[Naming] Remove postfix `_m` for merge and compress intrinsic functions.

[Hsiangkai]

Agree with that. _m is used to distinguish 'masked version' of intrinsics from 'non-masked version'. If the instructions are always masked, there is no need to append _m to the intrinsics name.

[ebahapo]

I disagree. I'd rather keep the _m for all masked intrinsics, regardless of whether there's a non masked version. It's just easier to remember, IMO.

[ebahapo]

Take the example of vcompress_vm_i8m1_m(). As it uses a mask operand, it makes more sense to me that it has the _m suffix. I acknowledge that it's redundant, but it's easier to remember: if there's a mask operand, it has the suffix; if it has the suffix, there's a mask operand. It just seems more orthogonal to me and doesn't require me to remember that, though an instruction has a mask operand, there isn't a version without a mask operand.

[Hsiangkai]

Instruction suffix m is already encoded in the intrinsic name. For example,

vmsbf.m vd, vs2, vm
vbool1_t vmsbf_m_b1 (vbool1_t op1);  // non-masked version
vbool1_t vmsbf_m_b1_m (vbool1_t mask, vbool1_t maskedoff, vbool1_t op1);  // masked version

The ending _m in intrinsics is used to differentiate the masked version from the non-masked version when the instructions has vm argument.

The issue talks about _m is needed for vcompress.vm vd, vs2, vs1 or not. If we append _m to it, it will become vcompress_vm_i8m1_m. Methink _m is redundant in this case. There is no vm argument for vcompress.vm and instruction suffix m is already encoded in vcompress_vm in the intrinsic name.

[kito-cheng]

No strong opinion on this.

@rofirrim @knightsifive @rdolbeau @PkmX @rjiejie do you mind give some feedback on this?

[zakk0610]

If the design is having mask operand need to have _m suffix, does it mean viota.m or vpopc.m also need to have _m suffix?
it causes other problem because those two operations have mask and non-mask operations.

Looking to other target's intrinsic design, X86 permutex instruction supports mask and non-mask operation so it does not have any problem of naming.

__m128i _mm_permutex2var_epi16 (__m128i a, __m128i idx, __m128i b)
__m128i _mm_maskz_permutex2var_epi16 (__mmask8 k, __m128i a, __m128i idx, __m128i b)

In SVE, the merging operations always have _m suffix, but in "Permutation and selection section" all of intrinsic functions have no _m suffix,
for example, SEL: Conditionally select elements from two inputs API looks like

svint8_t svsel[_s8](svbool_t pg, svint8_t op1, svint8_t op2)
svint16_t svsel[_s16](svbool_t pg, svint16_t op1, svint16_t op2

IMPO, as a user view, maybe having a _m suffix is something like this instruction (merge/vcompress) support masked operation (similar to X86's permutex), so I prefer to removing _m suffix for them.

[rdolbeau]

I would rather we kept the _m suffix for all masked operations, same as @ebahapo. It's easier to remember and it makes things obvious.

The m part in names like vcompress.vm doesn't necessarily denote a mask; for instance in vadc_vvm_i8mf8 it's for the carry instead.

@zakk0610 From the document, viota.m has a _m variant already? vmerge is basically a masked move (with an extra operand for reasons I don't understand), so it should have _m IMHO. vcompress isn't a masked operation strictly speaking (the pattern of altered elements in the output is not the mask), so it probably should not use _m.

[rofirrim]

A criterium we could use is if the operation has a mask input and we want to have a merge/dest for the inactive (masked-off) elements, then we mark that intrinsic with _m.

vcompress is a bit special in that the "uncompressed" elements belong to the tail (according to the spec), i.e. not the inactive (masked-off) elements. So strictly we should go without _m here.

Regarding vmerge, the current prototype looks like vmaskop ? va : vb which I think is familiar to C programmers. But as @rdolbeau mentions, we could understand it as well as a vmv_*_m where we have a merge/dest operand (corresponding to vb) and a single input va. I don't have strong opinion on that other than the current form seems fine to me (but I can understand it may be a bit surprising to some users).

What do you think?

[ebahapo]

Personally, I regard vcompress as a masked operation. After all, some input elements are indeed masked off or unused producing the output. Similarly, vmerge is always masked. What I'm suggesting that we help on a couple of issues: the programmer should not have to know all the V ISA to tell whether a masked instruction has an unmasked version and in the future there might come to be an unmasked version of instruction that is currently masked only.

Again, I prefer to reflect the instructions in the intrinsics uncritically, without editions, as much as possible. So, if the instruction itself has an m suffix, the intrinsic should also have an _m suffix, in general.

As @rdolbeau pointed out, there is a masked and an unmasked version of viota.

PS: methinks that the x86 SIMD extensions are a mess that we should avoid peeking at. 😀

[Hsiangkai]

The suffix of instructions is used to encode the types of input operands. For example, vcompress.vm has two input operands, the first is vector group type and the second is mask vector type. From this point of view, it is not a masked operation. It just has a second input operand with mask vector type. From the syntax of vcompress.vm in V specification,

vcompress.vm vd, vs2, vs1

Users will not aware it is a masked operation.

Similarly, vmerge.vvm has three input operands. They are vector group, vector group, and mask vector type. The third input operand is happened to be mask vector type and it is not used as a predicate in the instruction. I agree with that it is very similar to masked instructions. To treat this instruction as masked operation or not is fine to me.

I agree with @rofirrim. If we apply the rule “if the operation has a mask input and we want to have a merge/dest for the inactive (masked-off) elements, then we mark that intrinsic with _m”, it may make sense. vmerge has no need to specify masked-off elements. So, vmerge will not have _m under the rule.

[eopXD]

The intrinsic doc and mainstream compilers (LLVM, GCC) have removed the postfixes. Closing this issue.