To determine the trap cause, without such a bit, software will have to examine many possible vtype settings that are unique for each particular instruction. The trap handler will be highly customized

I guess simpler examples are anytime you use v0 as mask and a data source. These aren't useful use-cases, so existing software shouldn't have been doing this (except test code). Krste | On Mon, Nov

https://godbolt.org/z/qj6WzYc76

I'm not sure if C intrinsics can generate this case, but there are other cases where dynamic value settings can result in illegal instruction traps, so the result would be the same

I went with #3 in the updated text - this is the smallest delta from the frozen spec. Note that the worst case was something like: vfwmacc.vv v0, v0, v0, v0.t with SEW=32b, v0 is read/written as a

Surely possible; the fix would be to explicitly move the smaller operand to a non-overlapping register.

Is it possible to generate one of these cases from C with crazy uses of vreinterpret and vget/vset intrinsics? What should the compiler do for such code? Craig

There’s no benefit to setting vill versus just taking a trap in this case. Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a

Ok, this makes the opcodes virtually useless for other instructions. Instead, shouldn't we be setting a bit similar to vill? I realize vill is only set on illegal vset* instructions; in this case it

Valid point, I was thinking of the scalar encoding spaces.

I'm OK with going with #3 - it provides most flexibility to deal with in future, even if we just go with illegal instruction exception, and avoids adding tests to the compatibility suite. Krste | On

I think these encodings are qualitatively different from other nooks and crannies, since their availability is a function of the dynamic vtype setting. So we can rationalize the departure from the

If I understand correctly, #3 is like #1 near-term (for conforming implementations), but keeps the possibility open to later changing from "always illegal exception" to something else. I'd vote for #1

I'm glad this came up. I certainly wouldn't want to try to make an implementation work for these cases. 😊 I lean a bit toward #3, not so much because we might use the space as because I think

| We do have a choice of: | 1) Mandate all implementations raise an illegal exception in this | case.  This is my preferred route, as this would be a minor errata for | existing

That’s great news, thanks Krste! … haha i tried but can’t think of a use case !! I don’t have a strong opinion, but I prefer a route that allows us to recover those instruction encodings —

Apart from requests for more instructions, which can be handled with later extensions, there were no real substantive updates. I did notice one issue at end of public review, however. The current

As usual, Krste is completely right. This was a matter of OpenOCD not doing what I thought it was doing. Thanks for your help. Tim

Still could be worth a non-normative comment saying something like “even though there may not be a separate bit for vill, if the source register of a vsetvl instruction has bit XLEN-1 set, vtype