From 2fa87ab52476fcf5554c0e57a555dcc10b8730e1 Mon Sep 17 00:00:00 2001 From: Arthur Eubanks Date: Thu, 10 Feb 2022 14:24:04 -0800 Subject: [PATCH] [docs] Replace `opt -analyze` with better alternatives. `opt -analyze` is legacy PM-specific. Show better ways of doing the same thing, generally with some sort of `-passes=print`. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D119486 --- llvm/docs/CommandGuide/opt.rst | 23 ++++-------- llvm/docs/LoopTerminology.rst | 36 +++++++++---------- llvm/docs/TestingGuide.rst | 2 +- .../MyFirstLanguageFrontend/LangImpl05.rst | 2 +- llvm/include/llvm/Analysis/RegionInfo.h | 2 +- llvm/utils/update_analyze_test_checks.py | 2 +- 6 files changed, 28 insertions(+), 39 deletions(-) diff --git a/llvm/docs/CommandGuide/opt.rst b/llvm/docs/CommandGuide/opt.rst index 7ae9d330c759..f067f6253a19 100644 --- a/llvm/docs/CommandGuide/opt.rst +++ b/llvm/docs/CommandGuide/opt.rst @@ -11,23 +11,12 @@ SYNOPSIS 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 index 8ef77f9acaea..8b8086f0a46c 100644 --- a/llvm/docs/LoopTerminology.rst +++ b/llvm/docs/LoopTerminology.rst @@ -17,16 +17,16 @@ on the following definition. 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 @@ Terminology 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 @@ The definition of a loop comes with some additional terminology: * 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 @@ Important Notes 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 @@ same node. :ref:`loopinfo` reports this as: .. 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 @@ same node. :ref:`loopinfo` reports this as: :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 @@ same node. :ref:`loopinfo` reports this as: :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 @@ detect the loop and ensure separate headers for the outer and inner loop. .. 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 @@ has a more formal definition, which basically says that every cycle has 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 @@ a dominating header. } -* 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 @@ into the loop to ensure that the optimizer does not make this assumption 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 index d0f890dd0a09..80a6ba47d7b3 100644 --- a/llvm/docs/TestingGuide.rst +++ b/llvm/docs/TestingGuide.rst @@ -297,7 +297,7 @@ assertions: .. 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 index cc7ffe58918a..b517844ba77c 100644 --- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst +++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst @@ -214,7 +214,7 @@ Kaleidoscope looks like this: 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 index 9a32df3882d6..612b977f1ffa 100644 --- a/llvm/include/llvm/Analysis/RegionInfo.h +++ b/llvm/include/llvm/Analysis/RegionInfo.h @@ -242,7 +242,7 @@ public: /// /// 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 index 730346726a7d..cfb063294364 100755 --- a/llvm/utils/update_analyze_test_checks.py +++ b/llvm/utils/update_analyze_test_checks.py @@ -14,7 +14,7 @@ Workflow: 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.