<div dir="ltr">Hi!<div><br></div><div>This commit is just a doc update in LLVM, so I don't think it would break an OpenMP test in clang. :)</div><div><br></div><div>Looking at the builds since then (specifically #119 and #120), it seems that the OpenMP test failure has vanished, but other tests are now consistently failing; all of the failing tests say "llvm-dis: Could not open [...]: no such file or directory,"</div><div><br></div><div>I'm not sure what commit could have caused this. :/</div><div><br></div><div>Thanks,</div><div>George</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 18, 2016 at 2:35 PM, Galina Kistanova <span dir="ltr"><<a href="mailto:gkistanova@gmail.com" target="_blank">gkistanova@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello George,<br><br>It looks like this commit broke one of our new builders on staging master:<br><br><a href="http://lab.llvm.org:8014/builders/clang-with-lto-ubuntu/builds/117" target="_blank">http://lab.llvm.org:8014/build<wbr>ers/clang-with-lto-ubuntu/buil<wbr>ds/117</a><br><br>The previous revision r279002 id green<br><a href="http://lab.llvm.org:8014/builders/clang-with-lto-ubuntu/builds/116" target="_blank">http://lab.llvm.org:8014/build<wbr>ers/clang-with-lto-ubuntu/buil<wbr>ds/116</a><br><br>Please have a look at this?<br>I am going to move the builder from staging to main master today.<br><br>Thanks<span><font color="#888888"><br><br>Galina<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 17, 2016 at 4:21 PM, George Burgess IV via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Author: gbiv<br>
Date: Wed Aug 17 18:21:56 2016<br>
New Revision: 279007<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=279007&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-pr<wbr>oject?rev=279007&view=rev</a><br>
Log:<br>
[Docs] Update MemorySSA doc to address more feedback.<br>
<br>
Primarily, this clarifies wording in a few places, and adds "\ "s to<br>
make the formatting of things like "``Foo`` s" better.<br>
<br>
Thanks to Michael Kuperstein for the comments.<br>
<br>
Modified:<br>
llvm/trunk/docs/MemorySSA.rst<br>
<br>
Modified: llvm/trunk/docs/MemorySSA.rst<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/MemorySSA.rst?rev=279007&r1=279006&r2=279007&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-pr<wbr>oject/llvm/trunk/docs/MemorySS<wbr>A.rst?rev=279007&r1=279006&r2=<wbr>279007&view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/docs/MemorySSA.rst (original)<br>
+++ llvm/trunk/docs/MemorySSA.rst Wed Aug 17 18:21:56 2016<br>
@@ -36,8 +36,8 @@ MemorySSA Structure<br>
===================<br>
<br>
MemorySSA is a virtual IR. After it's built, ``MemorySSA`` will contain a<br>
-structure that maps ``Instruction`` s to ``MemoryAccess`` es, which are<br>
-``MemorySSA``'s parallel to LLVM ``Instruction`` s.<br>
+structure that maps ``Instruction``\ s to ``MemoryAccess``\ es, which are<br>
+``MemorySSA``'s parallel to LLVM ``Instruction``\ s.<br>
<br>
Each ``MemoryAccess`` can be one of three types:<br>
<br>
@@ -45,25 +45,25 @@ Each ``MemoryAccess`` can be one of thre<br>
- ``MemoryUse``<br>
- ``MemoryDef``<br>
<br>
-``MemoryPhi`` s are ``PhiNode`` , but for memory operations. If at any<br>
-point we have two (or more) ``MemoryDef`` s that could flow into a<br>
+``MemoryPhi``\ s are ``PhiNode``\ s, but for memory operations. If at any<br>
+point we have two (or more) ``MemoryDef``\ s that could flow into a<br>
``BasicBlock``, the block's top ``MemoryAccess`` will be a<br>
-``MemoryPhi``. As in LLVM IR, ``MemoryPhi`` s don't correspond to any<br>
-concrete operation. As such, you can't look up a ``MemoryPhi`` with an<br>
-``Instruction`` (though we do allow you to do so with a<br>
-``BasicBlock``).<br>
+``MemoryPhi``. As in LLVM IR, ``MemoryPhi``\ s don't correspond to any<br>
+concrete operation. As such, ``BasicBlock``\ s are mapped to ``MemoryPhi``\ s<br>
+inside ``MemorySSA``, whereas ``Instruction``\ s are mapped to ``MemoryUse``\ s<br>
+and ``MemoryDef``\ s.<br>
<br>
Note also that in SSA, Phi nodes merge must-reach definitions (that<br>
is, definite new versions of variables). In MemorySSA, PHI nodes merge<br>
may-reach definitions (that is, until disambiguated, the versions that<br>
reach a phi node may or may not clobber a given variable)<br>
<br>
-``MemoryUse`` s are operations which use but don't modify memory. An example of<br>
+``MemoryUse``\ s are operations which use but don't modify memory. An example of<br>
a ``MemoryUse`` is a ``load``, or a ``readonly`` function call.<br>
<br>
-``MemoryDef`` s are operations which may either modify memory, or which<br>
-otherwise clobber memory in unquantifiable ways. Examples of ``MemoryDef`` s<br>
-include ``store`` s, function calls, ``load`` s with ``acquire`` (or higher)<br>
+``MemoryDef``\ s are operations which may either modify memory, or which<br>
+otherwise clobber memory in unquantifiable ways. Examples of ``MemoryDef``\ s<br>
+include ``store``\ s, function calls, ``load``\ s with ``acquire`` (or higher)<br>
ordering, volatile operations, memory fences, etc.<br>
<br>
Every function that exists has a special ``MemoryDef`` called ``liveOnEntry``.<br>
@@ -73,12 +73,12 @@ run on, and implies that we've hit the t<br>
``liveOnEntry`` implies that the memory being used is either undefined or<br>
defined before the function begins.<br>
<br>
-An example of all of this overlayed on LLVM IR (obtained by running ``opt<br>
+An example of all of this overlaid on LLVM IR (obtained by running ``opt<br>
-passes='print<memoryssa>' -disable-output`` on an ``.ll`` file) is below. When<br>
viewing this example, it may be helpful to view it in terms of clobbers. The<br>
operands of a given ``MemoryAccess`` are all (potential) clobbers of said<br>
MemoryAccess, and the value produced by a ``MemoryAccess`` can act as a clobber<br>
-for other ``MemoryAccess`` es. Another useful way of looking at it is in<br>
+for other ``MemoryAccess``\ es. Another useful way of looking at it is in<br>
terms of heap versions. In that view, operands of of a given<br>
``MemoryAccess`` are the version of the heap before the operation, and<br>
if the access produces a value, the value is the new version of the heap<br>
@@ -125,7 +125,7 @@ to (if such an instruction exists). For<br>
is a ``MemoryAccess`` (specifically, a ``MemoryDef``), and it describes the LLVM<br>
instruction ``store i8 0, i8* %p3``. Other places in ``MemorySSA`` refer to this<br>
particular ``MemoryDef`` as ``1`` (much like how one can refer to ``load i8, i8*<br>
-%p1`` in LLVM with ``%1``). Again, ``MemoryPhi`` s don't correspond to any LLVM<br>
+%p1`` in LLVM with ``%1``). Again, ``MemoryPhi``\ s don't correspond to any LLVM<br>
Instruction, so the line directly below a ``MemoryPhi`` isn't special.<br>
<br>
Going from the top down:<br>
@@ -135,7 +135,9 @@ Going from the top down:<br>
``MemoryPhi`` is referred to in the textual IR by the number ``6``.<br>
- ``2 = MemoryDef(6)`` notes that ``store i8 0, i8* %p1`` is a definition,<br>
and its reaching definition before it is ``6``, or the ``MemoryPhi`` after<br>
- ``while.cond``.<br>
+ ``while.cond``. (See the `Build-time use optimization`_ and `Precision`_<br>
+ sections below for why this ``MemoryDef`` isn't linked to a seperate,<br>
+ disambiguated ``MemoryPhi``.)<br>
- ``3 = MemoryDef(6)`` notes that ``store i8 0, i8* %p2`` is a definition; its<br>
reaching definition is also ``6``.<br>
- ``5 = MemoryPhi({if.then,2},{if.else<wbr>,3})`` notes that the clobber before<br>
@@ -146,9 +148,9 @@ Going from the top down:<br>
reaching definition is ``5``.<br>
- ``MemoryUse(1)`` notes that ``load i8, i8* %p3`` is just a user of memory,<br>
and the last thing that could clobber this use is above ``while.cond`` (e.g.<br>
- the store to ``%p3``). In heap versioning parlance, it really<br>
- only depends on the heap version 1, and is unaffected by the new<br>
- heap versions generated since then.<br>
+ the store to ``%p3``). In heap versioning parlance, it really only depends on<br>
+ the heap version 1, and is unaffected by the new heap versions generated since<br>
+ then.<br>
<br>
As an aside, ``MemoryAccess`` is a ``Value`` mostly for convenience; it's not<br>
meant to interact with LLVM IR.<br>
@@ -158,9 +160,9 @@ Design of MemorySSA<br>
<br>
``MemorySSA`` is an analysis that can be built for any arbitrary function. When<br>
it's built, it does a pass over the function's IR in order to build up its<br>
-mapping of ``MemoryAccess`` es. You can then query ``MemorySSA`` for things like<br>
-the dominance relation between ``MemoryAccess`` es, and get the ``MemoryAccess``<br>
-for any given ``Instruction`` .<br>
+mapping of ``MemoryAccess``\ es. You can then query ``MemorySSA`` for things<br>
+like the dominance relation between ``MemoryAccess``\ es, and get the<br>
+``MemoryAccess`` for any given ``Instruction`` .<br>
<br>
When ``MemorySSA`` is done building, it also hands you a ``MemorySSAWalker``<br>
that you can use (see below).<br>
@@ -171,7 +173,7 @@ The walker<br>
<br>
A structure that helps ``MemorySSA`` do its job is the ``MemorySSAWalker``, or<br>
the walker, for short. The goal of the walker is to provide answers to clobber<br>
-queries beyond what's represented directly by ``MemoryAccess`` es. For example,<br>
+queries beyond what's represented directly by ``MemoryAccess``\ es. For example,<br>
given:<br>
<br>
.. code-block:: llvm<br>
@@ -190,10 +192,11 @@ The store to ``%a`` is clearly not a clo<br>
be the walker's goal to figure this out, and return ``liveOnEntry`` when queried<br>
for the clobber of ``MemoryAccess`` ``2``.<br>
<br>
-By default, ``MemorySSA`` provides a walker that can optimize ``MemoryDef`` s<br>
-and ``MemoryUse`` s by consulting alias analysis. Walkers were built to be<br>
-flexible, though, so it's entirely reasonable (and expected) to create more<br>
-specialized walkers (e.g. one that queries ``GlobalsAA``).<br>
+By default, ``MemorySSA`` provides a walker that can optimize ``MemoryDef``\ s<br>
+and ``MemoryUse``\ s by consulting whatever alias analysis stack you happen to<br>
+be using. Walkers were built to be flexible, though, so it's entirely reasonable<br>
+(and expected) to create more specialized walkers (e.g. one that specifically<br>
+queries ``GlobalsAA``, one that always stops at ``MemoryPhi`` nodes, etc).<br>
<br>
<br>
Locating clobbers yourself<br>
@@ -201,22 +204,23 @@ Locating clobbers yourself<br>
<br>
If you choose to make your own walker, you can find the clobber for a<br>
``MemoryAccess`` by walking every ``MemoryDef`` that dominates said<br>
-``MemoryAccess``. The structure of ``MemoryDef`` s makes this relatively simple;<br>
+``MemoryAccess``. The structure of ``MemoryDef``\ s makes this relatively simple;<br>
they ultimately form a linked list of every clobber that dominates the<br>
``MemoryAccess`` that you're trying to optimize. In other words, the<br>
``definingAccess`` of a ``MemoryDef`` is always the nearest dominating<br>
``MemoryDef`` or ``MemoryPhi`` of said ``MemoryDef``.<br>
<br>
<br>
-Use optimization<br>
-----------------<br>
+Build-time use optimization<br>
+---------------------------<br>
<br>
-``MemorySSA`` will optimize some ``MemoryAccess`` es at build-time.<br>
+``MemorySSA`` will optimize some ``MemoryAccess``\ es at build-time.<br>
Specifically, we optimize the operand of every ``MemoryUse`` to point to the<br>
actual clobber of said ``MemoryUse``. This can be seen in the above example; the<br>
second ``MemoryUse`` in ``if.end`` has an operand of ``1``, which is a<br>
``MemoryDef`` from the entry block. This is done to make walking,<br>
value numbering, etc, faster and easier.<br>
+<br>
It is not possible to optimize ``MemoryDef`` in the same way, as we<br>
restrict ``MemorySSA`` to one heap variable and, thus, one Phi node<br>
per block.<br>
@@ -228,13 +232,13 @@ Invalidation and updating<br>
Because ``MemorySSA`` keeps track of LLVM IR, it needs to be updated whenever<br>
the IR is updated. "Update", in this case, includes the addition, deletion, and<br>
motion of ``Instructions``. The update API is being made on an as-needed basis.<br>
-If you'd like examples, ``GVNHoist`` is a user of ``MemorySSA`` s update API.<br>
+If you'd like examples, ``GVNHoist`` is a user of ``MemorySSA``\ s update API.<br>
<br>
<br>
Phi placement<br>
^^^^^^^^^^^^^<br>
<br>
-``MemorySSA`` only places ``MemoryPhi`` s where they're actually<br>
+``MemorySSA`` only places ``MemoryPhi``\ s where they're actually<br>
needed. That is, it is a pruned SSA form, like LLVM's SSA form. For<br>
example, consider:<br>
<br>
@@ -274,7 +278,7 @@ for ``if.end`` would be pointless, so we<br>
place a ``MemoryDef`` in ``if.then`` or ``if.else``, you'll need to also create<br>
a ``MemoryPhi`` for ``if.end``.<br>
<br>
-If it turns out that this is a large burden, we can just place ``MemoryPhi`` s<br>
+If it turns out that this is a large burden, we can just place ``MemoryPhi``\ s<br>
everywhere. Because we have Walkers that are capable of optimizing above said<br>
phis, doing so shouldn't prohibit optimizations.<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>