(no commit message)

diff --git a/openpower/sv/rfc/ls009.mdwn b/openpower/sv/rfc/ls009.mdwn
index dc9c788c27e983ffa6d9aa352d41429d683edfca..8ab6438c53aca45bbbca9c4b9e4b6c90f9d10873 100644 (file)
--- a/openpower/sv/rfc/ls009.mdwn
+++ b/openpower/sv/rfc/ls009.mdwn
@@ -423,7 +423,7 @@ in the prior Parallel-Reduction instruction.
   first element with a predicate bit set.
 
 In either case the result is in the element with the first bit set in
-the predicate mask.
+the predicate mask. Thus, no move/copy *within the Reduction itself* was needed.
 
 Programmer's Note: For *some* hardware implementations
 the vector-to-scalar copy may be a slow operation, as may the Predicated
@@ -432,7 +432,7 @@ It may be better to perform a pre-copy
 of the values, compressing them (VREDUCE-style) into a contiguous block,
 which will guarantee that the result goes into the very first element
 of the destination vector, in which case clearly no follow-up
-vector-to-scalar MV operation is needed.
+predicated vector-to-scalar MV operation is needed.
 
 **Usage conditions**
 
@@ -592,7 +592,7 @@ Interrupt occur between the two instructions. Thus, Interrupts must be prohibite
 from occurring or other workaround deployed.  When persistence is set this issue
 is moot.
 
-It is critical to note that if persistence is clear `svremap` is the **only** way
+It is critical to note that if persistence is clear then `svremap` is the *only* way
 to activate REMAP on any given (following) instruction.  If persistence is set however then
 **all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.