[Docs] More MemorySSA doc updates!
authorGeorge Burgess IV <george.burgess.iv@gmail.com>
Thu, 18 Aug 2016 02:56:05 +0000 (02:56 +0000)
committerGeorge Burgess IV <george.burgess.iv@gmail.com>
Thu, 18 Aug 2016 02:56:05 +0000 (02:56 +0000)
Thanks again to Michael Kuperstein for the feedback.

llvm-svn: 279032

llvm/docs/MemorySSA.rst

index dcb0881..944df29 100644 (file)
@@ -53,16 +53,16 @@ concrete operation. As such, ``BasicBlock``\ s are mapped to ``MemoryPhi``\ s
 inside ``MemorySSA``, whereas ``Instruction``\ s are mapped to ``MemoryUse``\ s
 and ``MemoryDef``\ s.
 
-Note also that in SSA, Phi nodes merge must-reach definitions (that
-is, definite new versions of variables).  In MemorySSA, PHI nodes merge
-may-reach definitions (that is, until disambiguated, the versions that
-reach a phi node may or may not clobber a given variable)
+Note also that in SSA, Phi nodes merge must-reach definitions (that is,
+definitions that *must* be new versions of variables). In MemorySSA, PHI nodes
+merge may-reach definitions (that is, until disambiguated, the versions that
+reach a phi node may or may not clobber a given variable).
 
 ``MemoryUse``\ s are operations which use but don't modify memory. An example of
 a ``MemoryUse`` is a ``load``, or a ``readonly`` function call.
 
 ``MemoryDef``\ s are operations which may either modify memory, or which
-otherwise clobber memory in unquantifiable ways. Examples of ``MemoryDef``\ s
+introduce some kind of ordering constraints. Examples of ``MemoryDef``\ s
 include ``store``\ s, function calls, ``load``\ s with ``acquire`` (or higher)
 ordering, volatile operations, memory fences, etc.