Utility of vmmv.m and vmv.v.v intrinsics

[topperc]

Shouldn't users be encouraged to use operator= to copy vectors like any other variable? Using a mv intrinsic guarantees an instruction is emitted by the compiler even if register allocation would allow the input and output to use the same register. Unless we teach the compiler to look for these operations and turn them into copies that register allocation can coalesce.

[HanKuanChen]

operator= is ambiguity. Users may want to copy a vector with only vl elements, while others may want to copy a vector with vlmax elements (when tail is undisturbed).

[zakk0610]

I'm not sure the operator= behavior is equal to vmv.v.v and vmmv.m.
Some people think operator= is VLMAX operation and mv intrinsics operate on vl element.
If they are different. I think the mv intrinsics are still useful.

[topperc]

Wouldn't the vmv.v.v intrinsic need an extra operand for the undisturbed values to be useful for tail undisturbed? Right now the register allocator will just use whatever register is convenient as the destination so you have no control.

[kito-cheng]

I would suggest operator= should have VLMAX semantic and then compiler could optimize to vmv.v.v if possible, user should use intrinsic if user only want to copy vl.

So I agree with @topperc, we should encourage user to use operator=.

[nick-knight]

What happens when using operator= on a type with fractional LMUL?

[topperc]

What happens when using operator= on a type with fractional LMUL?

I think it becomes a vmv1r.v if a copy is needed.

[topperc]

I forgot about VL when I started this issue, but there's been some good discussion here.

Using vmv.v.v can improve performance by limiting the number of elements copied. But forcing users to explicitly code all copies using intrinsics to get the best performance seems bad. Variables in C should be a different abstraction than hardware registers.

To handle the tail undisturbed case we need a new intrinsic that takes that undisturbed values as a second input. This would not apply to vmmv.m since I mask instructions are always tail agnostic if I'm reading the spec correctly.

[eopXD]

We currently have = with semantic of a whole vector register move (which is also vmv.v.v of VL=VLMAX).

We should explicitly emphasize this in the document of v1.0 since the assumption is necessary for redundant move eliminations.