Should reduction have a dest/merge operand?

[rofirrim]

Operations that generate a "scalar vector" (e.g. vmv.s.x, vfmv.s.f) have a dest operand of the kind of the destination so the original value, except element 0, can be preserved.

For instance

vint32m1_t vmv_s_x_i32m1 (vint32m1_t dst, int32_t src);

Reductions also generate "scalar vectors" but don't seem to have the same treatment.

vint32m1_t vredmax_vs_i32m2_i32m1 (vint32m2_t vector, vint32m1_t scalar);

Do we want to have a dest operand in this case? Like this:

vint32m1_t vredmax_vs_i32m2_i32m1 (vin32m1_t dest, vint32m2_t vector, vint32m1_t scalar);

I don't think it is super fundamental but maybe someone wants to preserve the other elements for some reason?

[kito-cheng]

vint32m1_t vredmax_vs_i32m2_i32m1 (vin32m1_t dest, vint32m2_t vector, vint32m1_t scalar);

This kind of interface, compiler need merge dest and scalar first, which might emit 1~2 extra instructions, those instructions might able to optimize out later, but it little violate current 1-1 mapping design principle.

And user can use vmv_s_x + vredmax_vs to get same semantics if they want, so I would prefer keep current interfcae.

[rofirrim]

Hi @kito-cheng, thanks for the comments.

I didn't expect scalar be merged into dest. Given that particular instruction

vredmax.vs  vd, vs2, vs1, vm   # vd[0] =  max( vs1[0] , vs2[*] )

The idea was to allow a way to control the rest of elements of vd that are not updated (vd[1:VLMAX-1]). We can achieve this if dest is stored in vd already, without extra instructions, right? (vector would be in vs2 and scalar in vs1)

Perhaps I'm missing something obvious here.

[kito-cheng]

@rofirrim I checked the v isa spec again, it's my mistake, and sounds like your proposal made the interface more consistent.

[zakk0610]

+1, I think it's a good idea for consistent interface.

[Hsiangkai]

I also agree with @rofirrim's proposal. If there is no objection, I will update the document for reduction operations.