From: Bruce Hoult <bruce@...>
Sent: Wednesday, November 17, 2021 4:24 PM
To: Krste Asanovic <krste@...>
Cc: Bill Huffman <huffman@...>; Grigorios Magklis <grigorios.magklis@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] RISC-V Vector Extension post-public review updates

 

EXTERNAL MAIL

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 was in early RVV drafts.

 

Yes, that needs to be considered as well.

 

I'm not sure how common that really is, and non-store uses can usually just use a vmerge.vmm at the end anyway, at the expense of possibly using extra registers.

 

While on the subject of future features, and somewhat related ... the one big thing I've noticed RVV lacking that SVE has is a non-faulting version of indexed loads ("gather") which creates a mask showing which elements were accessible. In SVE this goes into a CSR which can then be moved into a mask register, but of course with sufficient encoding bits you could directly put it into a normal register.

 

Traditional vector code doesn't really need this, but SVE has an aim to be able to vectorise all loops.

 

How does this contribute to vectorizing all loops?

I am curious as well.

It makes sense when the whole vector is participating and masking is the only means to limit processing, but we have vlen.

 

I think this was not included for security reasons rather than ignored.

Specifically no First Fault variant was included so that a single instruction could not capture large swaths of the memory map information.

Of course no faulting but flagging would be even worse.

 

     Bill

 

On Thu, Nov 18, 2021 at 7:48 AM Krste Asanovic <krste@...> wrote:

 

On Nov 17, 2021, at 10:43 AM, Bill Huffman <huffman@...> wrote:

-----Original Message-----
From: krste@... <krste@...> 
Sent: Wednesday, November 17, 2021 1:02 PM
To: Bill Huffman <huffman@...>
Cc: Grigorios Magklis <grigorios.magklis@...>; tech-vector-ext@...
Subject: RE: [RISC-V] [tech-vector-ext] RISC-V Vector Extension post-public review updates

 

My thinking for longer encoding is we would not add different mask registers, but instead possibly expand set of architectural vector registers.

 

Does that mean continuing to assume fusing a mask move with an instruction where desired?

 

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