(no commit message)

diff --git a/openpower/sv/remap.mdwn b/openpower/sv/remap.mdwn
index 70f614777fea0ade6ed7f93e20dbe2228b4c714a..334430cddb7ed96dc0eb72876afc6a9ebe73856f 100644 (file)
--- a/openpower/sv/remap.mdwn
+++ b/openpower/sv/remap.mdwn
@@ -608,21 +608,16 @@ notes from conversations:
 > already peocessed paths that go through vertices numbered < z, and it
 > adds paths that go through vertices numbered z.
 >
-> For this to work, the outer loop has to be the one on teh subscript that
+> For this to work, the outer loop has to be the one on the subscript that
 > bridges a and b (which in this case are teh same matrix, of course).
 
 # SUBVL Remap
 
-Remapping even of SUBVL (vec2/3/4) elements is permitted, as if the
-sub-vectir elements were simply part of the main VL loop.  This is the
-*complete opposite* of predication which **only** applies to the whole
-vec2/3/4.  In pseudocode this would be:
-
-      for (i = 0; i < VL; i++)
-        if (predval & 1<<i) # apply to VL not SUBVL
-          for (j = 0; j < SUBVL; j++)
-             id = i*SUBVL + j # not, "id=i".
-             ireg[RT+remap1(id)] ...
+Remapping of SUBVL (vec2/3/4) elements is not permitted: the vec2/3/4
+itself must be considered to be the "element".  To perform REMAP
+on the elements of a vec2/3/4, use Swizzle, Indexing, or add one
+extra dimension to Matrix REMAP, the inner dimension being the size
+of the Subvector (2, 3, or 4).
 
 The reason for allowing SUBVL Remaps is that some regular patterns using
 Swizzle which would otherwise require multiple explicit instructions