From an ISA definition point of view it doesn't make sense to forbid properly formed operations to benefit a specific hardware implementation. It's an ugly hack. If a given hardware implementation

In this case, the trap cause can be determined by looking at the vtype value and the instruction encoding (most only need to look at instruction encoding), independent of implementation. No

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