On Nov 15, 2021, at 3:24 PM, Krste Asanovic <krste@...> wrote:

On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@...> wrote:

On Mon, Nov 15, 2021 at 2:17 PM Bill Huffman <huffman@...> wrote:

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've called all the other similar corners of opcode space that don't make sense to implement "reserved."  Possibly that's because they might make sense someday and this won't.

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 normal practice of marking the state reserved.

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 would be a new bit which is only set on executing instructions that are incompatible with the current (but otherwise valid) vtype ?

Guy

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 discovery mechanism.

Krste

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