Yes, for safely vectorizing loops with indirect references and data dependent control flow. I didn’t see how the mask result did that. Having it be zero for all elements after the one that fails

The primary reason was lack of encoding space for non-unit-stride fault-on-first instructions. The security concern was being able to probe addresses to find accessible regions without free of being

Because otherwise you can't safely vectorise loops that do indirect array accesses (e.g. a[b[i]]) with data-dependent control flow. I don't think there is any additional security implication. I could

On 2021-11-17 4:32 p.m., Bill Huffman wrote: I am curious as well. It makes sense when the whole vector is participating and masking is the only means to limit processing, but

Don't forget some code may want to use a mask in inverted sense for individual instructions, without explicitly creating a new mask. This was not listed in the "wish list for 64 bits" below, but it

Not necessarily with a larger mask register specifier. For example, with 3b mask register specifier, we could expand to encode v0-v6 as mask sources with 111 meaning unmasked. Krste

-----Original Message----- From: krste@... <krste@...> Sent: Wednesday, November 17, 2021 1:02 PM To: Bill Huffman <huffman@...> Cc: Grigorios Magklis <grigorios.magklis@...>;

| From: Grigorios Magklis <grigorios.magklis@...> | Sent: Tuesday, November 16, 2021 12:03 PM | What is the thinking for when we go to >32-bit encodings with respect to vtype | and

On 2021-11-16 12:15 p.m., Bill Huffman wrote: Yes, absolutely. Many vector models historically have been co-processors with their own internal status. RVV integration is also

What is the thinking for when we go to >32-bit encodings with respect to vtype and masks? I assume that the longer encoding could encode SEW (and LMUL?) as an override of vtype. What about masks

-----Original Message----- From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic Sent: Tuesday, November 16, 2021 11:13 AM To: ghost <ghost@...> Cc: krste@...;

Almost all vector instructions already have to check their vector operands to make sure the register numbers are compatible with (dynamic) LMUL. This is further complicated in, e.g., the case 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 implementations (doesn't affect software),

I agree that #1 is the least unfortunate of the alternatives, but I want to raise a flag because I think there are larger considerations. AFAIK, the vector extensions are unique among proposed

| 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. A common goal in ISA design is

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