From e1f783c7326a8ca8f62870f4c60a373af949f695 Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 26 Oct 2020 21:27:11 +0000 Subject: [PATCH] --- openpower/sv/predication.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openpower/sv/predication.mdwn b/openpower/sv/predication.mdwn index 1ad4987e9..d3c722798 100644 --- a/openpower/sv/predication.mdwn +++ b/openpower/sv/predication.mdwn @@ -43,7 +43,7 @@ As well-known weaknesses that compromise performance, very little use of OE=1 is One of the design principles of SV is that the use of VL should be as closrly equivalent to a direct substitution of the scalar operations of the hardware for-loop as possible, as if those looped operations were actually in the instruction stream (as scalar operations) rather than being issued from the Vector loop. -The implications here are that *register dependency hazards still have to be respected inter-element*. +The implications here are that *register dependency hazards still have to be respected inter-element* even when (conceptually) pushed into the instruction stream from a hardware for-loop. Using a multi-issue out-of-order engine as the underlying microarchitectural basis this is not as difficult to achieve as it first seems (the hard work having been done by the Dependency Matrices). In addition, Vector Chaining should also be possible for a multi-issue out-of-order engine to cope with, as long as false (unnecessary) Dependency Hazards are not introduced in between Vectors, where the dependencies actually only exist between elements *in* the Vector. -- 2.30.2