how to naming when the operation returns the same type for different operand types

[riscv-non-isa]

how to naming when the operation returns the same type for different operand types

[rdolbeau]

Adding the full type of parameters everywhere is a bit overwhelming, that would be a lot of hassle for the users...

For Store (where it would be void), I think using the type of the vector parameter as a suffix is an adequate solution, as that is the 'output' to memory.

For functions where there is a namespace collision (same name, same return type, different parameters), then I would add some minimalistic differentiation in the parameters type - though using the full types of parameters is an option.

[kito-cheng]

+1 for make exception for load/store.

[zakk0610]

but reduction instruction vredsum.vs will looks like:

vint32m1_t vredsum_vi32m1si32m1_i32m1 (vint32m1_t vector, vint32m1_t scalar);
vint32m1_t vredsum_vi32m1si32m1_i32m2 (vint32m2_t vector, vint32m1_t scalar);

any idea?

[zakk0610]

apply the new rule for load/store intrinsic function would looks like:

// vlb.v  vd, (rs1), vm # 8b signed
vint8m1_t vlb_v_i8m1(const int8_t *base);
vint8m2_t vlb_v_i8m2(const int8_t *base);

// vsb.v  vs3, (rs1), vm  # 8b store
void vsb_vi8m1_void(int8_t *base, vint8m1_t value);
void vsb_vi8m2_void(int8_t *base, vint8m2_t value);

or only load/store have exception naming rule

void vsb_v_i8m1(int8_t *base, vint8m1_t value);
void vsb_v_i8m2(int8_t *base, vint8m2_t value);

any suggestion?

[zakk0610]

apply the new rule for vfmv.f.s rd, vs2 # f[rd] = vs2[0] (rs1=0)

original SiFive rule is

float32_t vmv_v_f32m1 (vfloat32m1_t src);
float32_t vmv_v_f32m8 (vfloat32m8_t src);

intrinsic function would looks like:

float32_t  vfmv_ff32_sv32m1_f32(vfloat32m1_t src);
float32_t  vfmv_ff32_sv32m8_f32(vfloat32m8_t src);

or

float32_t  vfmv_ff32sv32m1_f32(vfloat32m1_t src);
float32_t  vfmv_ff32sv32m8_f32(vfloat32m8_t src);

[nick-knight]

I'd like to join the conversation, but I'm unable to parse from the thread exactly what the issue is, or what the proposed resolutions are.

My understanding was that, for each assembly instruction, the return type uniquely identifies its operand types, and vice versa (a bijection). What are the exceptional cases?

[zakk0610]

About intrinsic function naming rule, EPI and SiFive agree encoding the destination type into function name, but there are some exception cases where the operation returns the same type for different operand types, for example: vpopc operation:

// old interface in SiFive proposal
unsigned long vpopc_m_b1 (vbool1_t op1);  //encode source operand type into function
unsigned long vpopc_m_b2 (vbool2_t op1);
unsigned long vpopc_m_b4 (vbool4_t op1);
unsigned long vpopc_m_b8 (vbool8_t op1);

We could not rename above functions via only encoding destination type because C does not support overloading.
This thread is trying to find a naming rule for those exception cases.

[Hsiangkai]

I propose a list of exceptional naming in https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#exceptions. Any suggestions?

[nick-knight]

@zakk0610 @Hsiangkai : wow, I was wrong, there are a whole bunch of exceptional cases! I'm fine with your proposal.

[Hsiangkai]

I have described the exception rules in https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#exceptions

It includes vector store, comparison operations, reduction operations, merge operations, vpopc.m and vfirst.m, and permutation operations. The operations mentioned by @zakk0610 are all included. I follow the suggestions provided by @rdolbeau. That is, to add some minimalistic differentiation in the parameters type. If there is no suggestions about the exceptional naming rules, we could close the issue.

[ebahapo]

I have the impression that using a Polish notation for the intrinsics signature may be overwhelming to the users. Rather, in keeping with the approximate correlation between instrinsics and instructions, adopting overloading intrinsics might be easier on the users.

[Hsiangkai]

I have the impression that using a Polish notation for the intrinsics signature may be overwhelming to the users. Rather, in keeping with the approximate correlation between instrinsics and instructions, adopting overloading intrinsics might be easier on the users.

We have plan to support C11 generic interface. It could leverage C11 _Generic keyword to support overloading in compile time for C. We still need to use some naming strategy to differentiate the intrinsics with different output types and the same input types.

I mentioned C11 generic interface in https://github.com/sifive/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#c11-generic-interface.