On 2021-11-17 5:36 p.m., Krste Asanovic wrote:
The primary reason was lack of encoding space for
non-unit-stride fault-on-first instructions.
However, we did discuss its merit; if it would trump the
encoding dificulties, see below -
The security concern was being able to probe addresses to
find accessible regions without free of being killed on
touching a prohibited region. It was noted that this is
still present even for unit-stride in supervisor mode when
using translation to arbitrarily probe supervisor physical
space. However, I believe these security concerns are
manageable through control mechanisms at higher privilege
On Nov 17, 2021, at 2:21 PM, Bruce Hoult <bruce@...
Thu, Nov 18, 2021 at 10:33 AM Bill
Bruce Hoult <bruce@...>
Sent: Wednesday, November 17,
2021 4:24 PM
To: Krste Asanovic <krste@...>
Cc: Bill Huffman <huffman@...>;
Grigorios Magklis <grigorios.magklis@...>;
Subject: Re: [RISC-V]
[tech-vector-ext] RISC-V Vector
Extension post-public review updates
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
needs to be considered as well.
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.
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
vector code doesn't really
need this, but SVE has an aim
to be able to vectorise all
How does this
contribute to vectorizing all
you can't safely vectorise loops that do
indirect array accesses (e.g. a[b[i]])
with data-dependent control flow.
there are two aspects here -
a) checking array indexes are within bounds, which absent
proof that the indexes are always in bound should be
We have a viable mechanism for that. The index values
are loaded into a vector register in any event.
Set a mask on the compare of the index values with a
b) handle a fault exceptions expeditiously by returning a
mask of would be faults.
This should be the exception case and therefore does
not need expediting.
As Krste says the OS level can provide a cooperative
mechanism to set a corresponding mask when exceptions
occur, if it is deemed the application [or system code]
But this feature does not mitigate the out of bound
array fetch. Many out of bounds locations can be in
Thus no need for instructions to have this feature
whether supporting all loop constructs or not.
I think this
was not included for security
reasons rather than ignored.
I don't think
there is any additional security
I could be
wrong, as I'm not an expert on SVE, but
I believe that even if the gather
operation is done (somewhat) in parallel
or in random order, the instruction
doesn't actually return a mask
indicating all the failed accesses. All
mask bits after the first element that
was inaccessible are also set to false.
The following code will process all the
initial elements and then invert the
mask and loop back and try to process
the tail starting from the first
inaccessible element, which will then
actually fault if the loop didn't exit
or skip that element based on program