Clarify tail handling

[ptomsich]

This PR clarifies element-status and tail-policy semantics for the Integrated Matrix Extension, bringing them into alignment with the base RISC-V V specification.

Define C tile tail policy

When VL selects fewer than the maximum number of columns (N_tile < N_tile_max), the inactive columns of the C accumulator tile are tail elements. Unlike ordinary vector instructions — where
tail-undisturbed requires a read-merge — IME multiply-accumulate instructions achieve undisturbed behaviour by write-skip: tail element positions are simply never written, so no read of the tail
portion of the C register group is required in either the vta=0 or vta=1 case. This removes a significant burden from outer-product engines and register-renaming implementations. The tile geometry
table gains an explicit N_tile_max = M_tile definition to anchor the tail boundary.

Align tile load/store masking and tail policy with base V

The tile load/store instruction descriptions (vmtl.v, vmts.v, vmttl.v, vmtts.v) previously described only the vm=0 "not written" case and used imprecise terminology. This commit rewrites the
relevant prose and pseudocode to match the four-category element-status model from the base V spec: active elements access memory normally; inactive elements (body, mask disabled) follow the vma
policy; tail elements (index ≥ VL) follow the vta policy; prestart elements are untouched. The init_masked_source call — which had no equivalent in regular vector stores and could spuriously raise
an illegal-instruction exception — is removed from the store pseudocode, replaced with the same read_vmask + direct mask-bit check used by the loads.

[joseemoreira]

I think there is still some confusion here. I am referring to the note about the C tile tail policy:

For IME multiply-accumulate instructions, undisturbed behavior requires no read — the instruction leaves tail element positions untouched — which permits hardware implementations (including outer-product engines and register-renaming machines) to process only the N_tile active columns of the C tile without referencing the tail portion of the C register group.

That is certainly true for the output registers that are entirely in the tail. But because we allow VL to be a multiple of λ (not λ²), the tail can begin in the middle of one of the output registers. That particular fraction of the tail needs to be read/written back, either unmodified or all "1"s. If the micro-architecture supports segmenting a register into chunks of λ elements, then yes, we can avoid reading those elements, but from the architecture perspective the register was read/modified/written.

[ptomsich]

without referencing the tail portion of the C register group

I would have hoped that this wording does capture exactly that tdetail: the tail-portion of the C register group (i.e., all registers that fall entirely into the tail) are untouched — and don't even have to be read.

Any suggestions in how we can capture this better?

[joseemoreira]

Hi Philipp, I think you have it, just add "(i.e., all registers that fall entirely into the tail)". I didn't see that in the text. Is "tail-portion of the C register group" a well-established terminology that does not require the parentheses clarification? For me, "tail-portion" (without the clarification) would mean the entire tail, including the partial register.