Re: Vector Memory Ordering
Andrew Waterman
On Fri, Sep 4, 2020 at 10:19 AM Bill Huffman <huffman@...> wrote:
This is not terribly straightforward. I'll assume that the trap would only be a function of the stride and element/segment width, rather than checking that two active elements actually overlap at runtime. Even so, very large strides can foul this up. Consider (in RV32) vssseg8e32 with vl=5 and stride=0xC0000004. Elements 0 and 4 overlap! (This phenomenon can also happen for non-segment strided stores by using a misaligned stride, which (for good reason) is a valid thing to do.) It's not an inexpensive computation in general. It would be better, I think, to either make them in-order or to permit arbitrary reordering than to trap.
Why is this change necessary? Currently, depending on EEW, non-segment indexed loads are allowed to overlap the index register. Are you suggesting that, not only can indexed loads access memory in arbitrary order, they can also write back imprecisely (past vstart), destroying the index register? (Mask register overlap is already forbidden by the usual rules for different-EEW overlap.)
|
|