"Vector Integer Add-with-Carry / Subtract-with-Borrow Functions" naming rule.

[riscv-non-isa]

"Vector Integer Add-with-Carry / Subtract-with-Borrow Functions" naming rule.

[zakk0610]

Hi KaunLin,

In order to keep consistent of naming in the same category instructions, there are some exceptions in generic functions naming.
For example, in your case, we can not use generic function vmsbc for vmsbc_vvm and vmsbc_vx due to they have different number of arguments, but we can use generic function vadc for vadc_vvm and vadc_vxm.

You can also note that load/store functions also does not have generic version, unit stride load without mask can not be generic but mask type can be, so we decide all load and store does not support generic function.

But in RFC we never discuss about generic function naming rule, do you have any suggestion?

ps. I found a bug in function list, in the same category, vector integer move functions have no generic for vmv_v_x_i8m1 but vmv_v_v have, I'm so sorry to confuse you.

Thanks.

[PkmX]

This issue is about the vadc and vsbc intrinsic functions, both of which still keep the _vvm and _vxm suffix in the C11 generic function list even though they can clearly be overloaded under the same name.

For vmadc and vmsbc, I think it is understandable that the _vvm and _vv versions cannot be overloaded together as they have different number of arguments (although it is actually possible with some preprocessor hackery).

I agree the RFC should be expanded to describe the rules of overloading and name shortening, as well as explaining any exceptions to these rules. Functions like load/store and vmv_v_x are good examples why they shouldn't or can't be overloaded.

[kuanlinchentw]

I understand why vadc keep its suffix now.
As I know, GCC can implement TARGET_RESOLVE_OVERLOADED_BUILTIN and Clang can use
overloadable to overload functions with different number of arguments. Maybe we'll have non-suffix vadc and vmadc in the future.

I agree with PkmX that RFC should describe more details about naming rule. Preferably keep the rule consistent and easy to remember. Although there are always exceptions in rules. lol. Thanks.

[Hsiangkai]

I provide the exceptional cases for C11 generic interface in https://github.com/riscv/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#c11-generic-interface.

How about we provide C11 generic interface for vadc/vsbc and treat vmadc/vmsbc as exceptions?