[Docs] update MemorySSA for opaque ptrs

[nikic]

LGTM

[asbirlea]

Thank you for updating this!

llvm/docs/MemorySSA.rst

 .. code-block:: llvm
 
   define void @foo() {
   entry:
     %p1 = alloca i8
     %p2 = alloca i8
     %p3 = alloca i8
     ; 1 = MemoryDef(liveOnEntry)
-    store i8 0, i8* %p3
+    store i8 0, ptr %p3
     br label %while.cond
 
   while.cond:
     ; 6 = MemoryPhi({entry,1},{if.end,4})
     br i1 undef, label %if.then, label %if.else
 
   if.then:
     ; 2 = MemoryDef(6)
-    store i8 0, i8* %p1
+    store i8 0, ptr %p1
     br label %if.end
 
   if.else:
     ; 3 = MemoryDef(6)
-    store i8 1, i8* %p2
+    store i8 1, ptr %p2
     br label %if.end
 
   if.end:
     ; 5 = MemoryPhi({if.then,2},{if.else,3})
     ; MemoryUse(5)
-    %1 = load i8, i8* %p1
+    %1 = load i8, ptr %p1
     ; 4 = MemoryDef(5)
-    store i8 2, i8* %p2
+    store i8 2, ptr %p2
     ; MemoryUse(1)
-    %2 = load i8, i8* %p3
+    %2 = load i8, ptr %p3
     br label %while.cond
   }
 
 The ``MemorySSA`` IR is shown in comments that precede the instructions they map
 to (if such an instruction exists). For example, ``1 = MemoryDef(liveOnEntry)``
 is a ``MemoryAccess`` (specifically, a ``MemoryDef``), and it describes the LLVM
-instruction ``store i8 0, i8* %p3``. Other places in ``MemorySSA`` refer to this
-particular ``MemoryDef`` as ``1`` (much like how one can refer to ``load i8, i8*
+instruction ``store i8 0, ptr %p3``. Other places in ``MemorySSA`` refer to this
+particular ``MemoryDef`` as ``1`` (much like how one can refer to ``load i8, ptr
 %p1`` in LLVM with ``%1``). Again, ``MemoryPhi``\ s don't correspond to any LLVM
 Instruction, so the line directly below a ``MemoryPhi`` isn't special.
 
 Going from the top down:
 
 - ``6 = MemoryPhi({entry,1},{if.end,4})`` notes that, when entering
   ``while.cond``, the reaching definition for it is either ``1`` or ``4``. This
   ``MemoryPhi`` is referred to in the textual IR by the number ``6``.
-- ``2 = MemoryDef(6)`` notes that ``store i8 0, i8* %p1`` is a definition,
+- ``2 = MemoryDef(6)`` notes that ``store i8 0, ptr %p1`` is a definition,
   and its reaching definition before it is ``6``, or the ``MemoryPhi`` after
   ``while.cond``. (See the `Use and Def optimization`_ and `Precision`_
   sections below for why this ``MemoryDef`` isn't linked to a separate,
   disambiguated ``MemoryPhi``.)
-- ``3 = MemoryDef(6)`` notes that ``store i8 0, i8* %p2`` is a definition; its
+- ``3 = MemoryDef(6)`` notes that ``store i8 0, ptr %p2`` is a definition; its
   reaching definition is also ``6``.
 - ``5 = MemoryPhi({if.then,2},{if.else,3})`` notes that the clobber before
   this block could either be ``2`` or ``3``.
-- ``MemoryUse(5)`` notes that ``load i8, i8* %p1`` is a use of memory, and that
+- ``MemoryUse(5)`` notes that ``load i8, ptr %p1`` is a use of memory, and that
   it's clobbered by ``5``.
-- ``4 = MemoryDef(5)`` notes that ``store i8 2, i8* %p2`` is a definition; its
+- ``4 = MemoryDef(5)`` notes that ``store i8 2, ptr %p2`` is a definition; its
   reaching definition is ``5``.
-- ``MemoryUse(1)`` notes that ``load i8, i8* %p3`` is just a user of memory,
+- ``MemoryUse(1)`` notes that ``load i8, ptr %p3`` is just a user of memory,
   and the last thing that could clobber this use is above ``while.cond`` (e.g.
   the store to ``%p3``). In memory versioning parlance, it really only depends on
   the memory version 1, and is unaffected by the new memory versions generated since
   then.
 
 As an aside, ``MemoryAccess`` is a ``Value`` mostly for convenience; it's not
 meant to interact with LLVM IR.
 

 
 .. code-block:: llvm
 
   define void @foo() {
     %a = alloca i8
     %b = alloca i8
 
     ; 1 = MemoryDef(liveOnEntry)
-    store i8 0, i8* %a
+    store i8 0, ptr %a
     ; 2 = MemoryDef(1)
-    store i8 0, i8* %b
+    store i8 0, ptr %b
   }
 
 The store to ``%a`` is clearly not a clobber for the store to ``%b``. It would
 be the walker's goal to figure this out, and return ``liveOnEntry`` when queried
 for the clobber of ``MemoryAccess`` ``2``.
 
 By default, ``MemorySSA`` provides a walker that can optimize ``MemoryDef``\ s
 and ``MemoryUse``\ s by consulting whatever alias analysis stack you happen to

 .. code-block:: llvm
 
   define void @foo() {
   entry:
     %p1 = alloca i8
     %p2 = alloca i8
     %p3 = alloca i8
     ; 1 = MemoryDef(liveOnEntry)
-    store i8 0, i8* %p3
+    store i8 0, ptr %p3
     br label %while.cond
 
   while.cond:
     ; 3 = MemoryPhi({%0,1},{if.end,2})
     br i1 undef, label %if.then, label %if.else
 
   if.then:
     br label %if.end
 
   if.else:
     br label %if.end
 
   if.end:
     ; MemoryUse(1)
-    %1 = load i8, i8* %p1
+    %1 = load i8, ptr %p1
     ; 2 = MemoryDef(3)
-    store i8 2, i8* %p2
+    store i8 2, ptr %p2
     ; MemoryUse(1)
-    %2 = load i8, i8* %p3
+    %2 = load i8, ptr %p3
     br label %while.cond
   }
 
 Because we removed the stores from ``if.then`` and ``if.else``, a ``MemoryPhi``
 for ``if.end`` would be pointless, so we don't place one. So, if you need to
 place a ``MemoryDef`` in ``if.then`` or ``if.else``, you'll need to also create
 a ``MemoryPhi`` for ``if.end``.
 
 If it turns out that this is a large burden, we can just place ``MemoryPhi``\ s
 everywhere. Because we have Walkers that are capable of optimizing above said
 phis, doing so shouldn't prohibit optimizations.
 
 
 Non-Goals
 ---------
 
 ``MemorySSA`` is meant to reason about the relation between memory
 operations, and enable quicker querying.
 It isn't meant to be the single source of truth for all potential memory-related
 optimizations. Specifically, care must be taken when trying to use ``MemorySSA``
 to reason about atomic or volatile operations, as in:
 
 .. code-block:: llvm
 
-  define i8 @foo(i8* %a) {
+  define i8 @foo(ptr %a) {
   entry:
     br i1 undef, label %if.then, label %if.end
 
   if.then:
     ; 1 = MemoryDef(liveOnEntry)
-    %0 = load volatile i8, i8* %a
+    %0 = load volatile i8, ptr %a
     br label %if.end
 
   if.end:
     %av = phi i8 [0, %entry], [%0, %if.then]
     ret i8 %av
   }
 
 Going solely by ``MemorySSA``'s analysis, hoisting the ``load`` to ``entry`` may