diff --git a/llvm/docs/CommandGuide/opt.rst b/llvm/docs/CommandGuide/opt.rst --- a/llvm/docs/CommandGuide/opt.rst +++ b/llvm/docs/CommandGuide/opt.rst @@ -11,23 +11,12 @@ DESCRIPTION ----------- -The :program:`opt` command is the modular LLVM optimizer and analyzer. It -takes LLVM source files as input, runs the specified optimizations or analyses -on it, and then outputs the optimized file or the analysis results. The -function of :program:`opt` depends on whether the `-analyze` option is -given. - -When `-analyze` is specified, :program:`opt` performs various analyses -of the input source. It will usually print the results on standard output, but -in a few cases, it will print output to standard error or generate a file with -the analysis output, which is usually done when the output is meant for another -program. - -While `-analyze` is *not* given, :program:`opt` attempts to produce an -optimized output file. The optimizations available via :program:`opt` depend -upon what libraries were linked into it as well as any additional libraries -that have been loaded with the :option:`-load` option. Use the :option:`-help` -option to determine what optimizations you can use. +The :program:`opt` command is the modular LLVM optimizer and analyzer. It takes +LLVM source files as input, runs the specified optimizations or analyses on it, +and then outputs the optimized file. The optimizations available via +:program:`opt` depend upon what libraries were linked into it as well as any +additional libraries that have been loaded with the :option:`-load` option. Use +the :option:`-help` option to determine what optimizations you can use. If ``filename`` is omitted from the command line or is "``-``", :program:`opt` reads its input from standard input. Inputs can be in either the LLVM assembly diff --git a/llvm/docs/LoopTerminology.rst b/llvm/docs/LoopTerminology.rst --- a/llvm/docs/LoopTerminology.rst +++ b/llvm/docs/LoopTerminology.rst @@ -17,16 +17,16 @@ A loop is a subset of nodes from the control-flow graph (CFG; where nodes represent basic blocks) with the following properties: -1. The induced subgraph (which is the subgraph that contains all the +1. The induced subgraph (which is the subgraph that contains all the edges from the CFG within the loop) is strongly connected (every node is reachable from all others). -2. All edges from outside the subset into the subset point to the same +2. All edges from outside the subset into the subset point to the same node, called the **header**. As a consequence, the header dominates all nodes in the loop (i.e. every execution path to any of the loop's node will have to pass through the header). -3. The loop is the maximum subset with these properties. That is, no +3. The loop is the maximum subset with these properties. That is, no additional nodes from the CFG can be added such that the induced subgraph would still be strongly connected and the header would remain the same. @@ -40,7 +40,7 @@ The definition of a loop comes with some additional terminology: -* An **entering block** (or **loop predecessor**) is a non-loop node +* An **entering block** (or **loop predecessor**) is a non-loop node that has an edge into the loop (necessarily the header). If there is only one entering block entering block, and its only edge is to the header, it is also called the loop's **preheader**. The preheader @@ -50,7 +50,7 @@ * A **backedge** is an edge from a latch to the header. -* An **exiting edge** is an edge from inside the loop to a node outside +* An **exiting edge** is an edge from inside the loop to a node outside of the loop. The source of such an edge is called an **exiting block**, its target is an **exit block**. @@ -63,17 +63,17 @@ This loop definition has some noteworthy consequences: -* A node can be the header of at most one loop. As such, a loop can be +* A node can be the header of at most one loop. As such, a loop can be identified by its header. Due to the header being the only entry into a loop, it can be called a Single-Entry-Multiple-Exits (SEME) region. -* For basic blocks that are not reachable from the function's entry, the +* For basic blocks that are not reachable from the function's entry, the concept of loops is undefined. This follows from the concept of dominance being undefined as well. -* The smallest loop consists of a single basic block that branches to +* The smallest loop consists of a single basic block that branches to itself. In this case that block is the header, latch (and exiting block if it has another edge to a different block) at the same time. A single block that has no branch to itself is not considered a loop, @@ -87,11 +87,11 @@ .. code-block:: console - $ opt input.ll -loops -analyze + $ opt input.ll -passes='print' Loop at depth 1 containing: %for.body
-* Loops can be nested inside each other. That is, a loop's node set can +* Loops can be nested inside each other. That is, a loop's node set can be a subset of another loop with a different loop header. The loop hierarchy in a function forms a forest: Each top-level loop is the root of the tree of the loops nested inside it. @@ -100,7 +100,7 @@ :width: 350 px -* It is not possible that two loops share only a few of their nodes. +* It is not possible that two loops share only a few of their nodes. Two loops are either disjoint or one is nested inside the other. In the example below the left and right subsets both violate the maximality condition. Only the merge of both sets is considered a loop. @@ -109,7 +109,7 @@ :width: 250 px -* It is also possible that two logical loops share a header, but are +* It is also possible that two logical loops share a header, but are considered a single loop by LLVM: .. code-block:: C @@ -130,7 +130,7 @@ .. image:: ./loop-separate.svg :width: 400 px -* A cycle in the CFG does not imply there is a loop. The example below +* A cycle in the CFG does not imply there is a loop. The example below shows such a CFG, where there is no header node that dominates all other nodes in the cycle. This is called **irreducible control-flow**. @@ -146,19 +146,19 @@ a dominating header. -* Irreducible control-flow can occur at any level of the loop nesting. +* Irreducible control-flow can occur at any level of the loop nesting. That is, a loop that itself does not contain any loops can still have cyclic control flow in its body; a loop that is not nested inside another loop can still be part of an outer cycle; and there can be additional cycles between any two loops where one is contained in the other. -* Exiting edges are not the only way to break out of a loop. Other +* Exiting edges are not the only way to break out of a loop. Other possibilities are unreachable terminators, [[noreturn]] functions, exceptions, signals, and your computer's power button. -* A basic block "inside" the loop that does not have a path back to the +* A basic block "inside" the loop that does not have a path back to the loop (i.e. to a latch or header) is not considered part of the loop. This is illustrated by the following code. @@ -188,7 +188,7 @@ } -* There is no requirement for the control flow to eventually leave the +* There is no requirement for the control flow to eventually leave the loop, i.e. a loop can be infinite. A **statically infinite loop** is a loop that has no exiting edges. A **dynamically infinite loop** has exiting edges, but it is possible to be never taken. This may happen @@ -215,7 +215,7 @@ without proof. -* The number of executions of the loop header before leaving the loop is +* The number of executions of the loop header before leaving the loop is the **loop trip count** (or **iteration count**). If the loop should not be executed at all, a **loop guard** must skip the entire loop: diff --git a/llvm/docs/TestingGuide.rst b/llvm/docs/TestingGuide.rst --- a/llvm/docs/TestingGuide.rst +++ b/llvm/docs/TestingGuide.rst @@ -297,7 +297,7 @@ .. code-block:: none update_analyze_test_checks.py - opt --analyze --costmodel + opt -passes='print' update_cc_test_checks.py C/C++, or clang/clang++ (IR checks) diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst --- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst +++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst @@ -214,7 +214,7 @@ To visualize the control flow graph, you can use a nifty feature of the LLVM '`opt `_' tool. If you put this LLVM -IR into "t.ll" and run "``llvm-as < t.ll | opt -analyze -view-cfg``", `a +IR into "t.ll" and run "``llvm-as < t.ll | opt -passes=view-cfg``", `a window will pop up <../../ProgrammersManual.html#viewing-graphs-while-debugging-code>`_ and you'll see this graph: diff --git a/llvm/include/llvm/Analysis/RegionInfo.h b/llvm/include/llvm/Analysis/RegionInfo.h --- a/llvm/include/llvm/Analysis/RegionInfo.h +++ b/llvm/include/llvm/Analysis/RegionInfo.h @@ -242,7 +242,7 @@ /// /// You can obtain more examples by either calling /// -/// "opt -regions -analyze anyprogram.ll" +/// "opt -passes='print' anyprogram.ll" /// or /// "opt -view-regions-only anyprogram.ll" /// diff --git a/llvm/utils/update_analyze_test_checks.py b/llvm/utils/update_analyze_test_checks.py --- a/llvm/utils/update_analyze_test_checks.py +++ b/llvm/utils/update_analyze_test_checks.py @@ -14,7 +14,7 @@ in regression test files. 2. Save the patch and revert it from your local work area. 3. Update the RUN-lines in the affected regression tests to look canonical. - Example: "; RUN: opt < %s -analyze -cost-model -S | FileCheck %s" + Example: "; RUN: opt < %s -passes='print' -disable-output 2>&1 | FileCheck %s" 4. Refresh the FileCheck lines for either the entire file or select functions by running this script. 5. Commit the fresh baseline of checks.