riscv-non-isa / rvv-intrinsic-doc

https://jira.riscv.org/browse/RVG-153
BSD 3-Clause "New" or "Revised" License
275 stars 87 forks source link

Renaming the VL arguments to AVL #348

Open lukel97 opened 1 week ago

lukel97 commented 1 week ago

§5.2 clarifies that the size_t vl argument is used to specify the AVL:

The intrinsics programmer specifies an "application vector length (AVL)" using the argument size_t vl.

I can't speak for others but I've often gotten vl (the register) confused with AVL (the vsetvli argument), and it would appear that there is precedent for clarifying this in the note below:

The actual value written to the vl control register is an implementation defined behavior and is typically not known until runtime. The actual setting of vl, given the provided AVL through the parameter, follows the rules 27 in the specification.

Given this, would it be worthwhile renaming the vl arguments to avl so that we call it what it is?

If it's just a matter of renaming an argument I think this should be backwards compatible.

topperc commented 1 week ago

For most use cases it probably isn't really the AVL because it came from a vsetvli intrinsic that already clipped it. Though I don't have a better name.

lukel97 commented 1 week ago

For most use cases it probably isn't really the AVL because it came from a vsetvli intrinsic that already clipped it.

Isn't that still the AVL though? The compiler might fold two equivalent vsetvlis into one, but IIUC that's still the same as setting the AVL to the output VL of a vsetvli.

topperc commented 1 week ago

I was thinking about it from the perspective of the programmer that probably wrote something like

while (n != 0) {
  size_t vl = vsetvli_e8m1(n);
  n -= vl;

  a = vadd(a, b, vl);
}

So to them it is the vl because there is a separate AVL they passed to the vsetvli intrinsic. Does the argument to the intrinsics cause confusion since its not the AVL from the programmers perspective in most cases.

I don't think I recommend passing an unclipped AVL to the intrinsics even though it is supported. Do our vsetvli optimizations work as well if you do that?

lukel97 commented 1 week ago

I don't think I recommend passing an unclipped AVL to the intrinsics even though it is supported. Do our vsetvli optimizations work as well if you do that?

I'm not sure. I agree though that clipping the AVL beforehand is what programmers should continue to do, if we were to rename the argument I was thinking that they would still write the same

while (n != 0) {
  size_t vl = vsetvli_e8m1(n);
  n -= vl;

  a = vadd(a, b, vl);
}

But the intrinsic signature would just make it more clear that they're setting the AVL to the precalculated vl.

Does the argument to the intrinsics cause confusion since its not the AVL from the programmers perspective in most cases.

I think it's more likely to cause confusion if they're not made aware that it's the AVL, e.g. if they accidentally change the SEW/LMUL ratio:

size_t vl = vsetvli_e32m1(n);
__riscv_vadd_vv_i32m1(a, b, vl); // vl guaranteed to equal vl
__riscv_vadd_vv_i64m1(c, d, vl); // vl not guaranteed to equal vl