Disallow VTYPE=VILL

Implementations are all over the place on whole register moves trapping
under VILL, so let's just forbid that case in the psABI.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

---

We've started seeing a bunch of fallout from the "whole register moves
depend on TYPE" ISA change, and there's discussion all over the place:

* There's a GCC bug
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117544>
* Also an LLVM bug <llvm/llvm-project#114518>
* QEMU changed behavior in 4eff52cd46 ("target/riscv: Add vill check for
  whole vector register move instructions")
* Philip has a writeup on some of the options in his notes
  <https://github.com/preames/public-notes/blob/master/riscv/whole-register-move-abi.rst>.
* This has also come up in most of the meetings I'v been in this week.

It seems like there's no general consensus on what we do here -- some
discussions say we're going to change the psABI (and presumably then the
uABI), some say we're not.  I don't personally care a ton if we make the
ABI change or not, we just need to decide so we can figure out where the
bugs are -- there's going to be fallout either way, but we can't really
get things fixed until we decide one way or the other.  As far as I can
tell both paths are valid:

* If we make these ABI changes then most code that predates the ISA
  change continues to function correctly after the ISA change.  We just
  need to track down anything that sets VILL and fix it, but we should
  be able to do that incrementally (maybe even just with a trap
  handler).  Right now I think that's just the kernel, but I'm not 100%
  sure there.  Looks like the first round of HW doesn't trap, though, so
  we should be safe for a bit.
* If we don't make these ABI changes then we'll have to fix the
  compilers and go rebuild everything to match the ISA change.  I think
  the GCC change should be pretty straight-forward, I don't know about
  the LLVM side of things.  I'm not sure what we'd do with the kernel
  here: we could say the VILL traps are just latent userspace bugs, or
  we could say we're breaking userspace -- kind of a grey area, so
  probably more of an LKML question.

I don't think one option is clearly simpler than the other, it's just a
question of where we push the bugs.

riscv-cc.adoc

@@ -107,7 +107,7 @@ duration in accordance with C11 section 7.6 "Floating-point environment
 
 | v0-v31  |              | Temporary registers          | No
 | vl      |              | Vector length                | No
-| vtype   |              | Vector data type register    | No
+| vtype   |              | Vector data type register    | No (but never `VILL`)
 | vxrm    |              | Vector fixed-point rounding mode register    | No
 | vxsat   |              | Vector fixed-point saturation flag register  | No
 |===
@@ -120,7 +120,11 @@ The `vxrm` and `vxsat` fields of `vcsr` are not preserved across calls and their
 values are unspecified upon entry.
 
 Procedures may assume that `vstart` is zero upon entry. Procedures may assume
-that `vstart` is zero upon return from a procedure call.
+that `vstart` is zero upon return from a procedure call.  Procedures may assume
+that `vtype` is never `VILL`.
+
+NOTE: Versions of the psABI before December 2024 allowed `vtype` to be `VILL`
+at arbitrary times.
 
 NOTE: Application software should normally not write `vstart` explicitly.
 Any procedure that does explicitly write `vstart` to a nonzero value must zero
@@ -137,7 +141,7 @@ Any procedure that does explicitly write `vstart` to a nonzero value must zero
 | v8-v23  |              | Argument registers           | No
 | v24-v31 |              | Callee-saved registers       | Yes
 | vl      |              | Vector length                | No
-| vtype   |              | Vector data type register    | No
+| vtype   |              | Vector data type register    | No (but never VILL)
 | vxrm    |              | Vector fixed-point rounding mode register    | No
 | vxsat   |              | Vector fixed-point saturation flag register  | No
 |===
@@ -150,8 +154,8 @@ attribute `riscv_vector_cc`).
 Please refer to the <<Standard Vector Calling Convention Variant>> section for
 more details about standard vector calling convention variant.
 
-NOTE: The `vxrm` and `vxsat` fields of `vcsr` follow the same behavior as the
-standard calling convention.
+NOTE: The `vxrm`,  `vxsat` and `vtype` fields of `vcsr` follow the same
+behavior as the standard calling convention.
 
 == Procedure Calling Convention