Lines Matching refs:passes
12 passes are where most of the interesting parts of the compiler exist. Passes
17 All LLVM passes are subclasses of the `Pass
28 passes. One of the main features of the LLVM Pass Framework is that it
29 schedules passes to run in an efficient way based on the constraints that your
39 Here we describe how to write the "hello world" of passes. The "Hello" pass is
208 contained in an anonymous namespace --- this reflects the fact that passes
265 nice command line option (:option:`--time-passes`) that allows you to get
266 information about the execution time of your pass along with the other passes
271 $ opt -load ../../Debug+Asserts/lib/Hello.so -hello -time-passes < hello.bc > /dev/null
288 passes listed are automatically inserted by the :program:`opt` tool to verify
292 Now that you have seen the basics of the mechanics behind passes, we can talk
310 optimize how passes are run, so that the resultant compiler isn't unnecessarily
318 type is used for passes that do not have to be run, do not change state, and
341 A module pass can use function level passes (e.g. dominators) using the
344 not require any module or immutable passes. Note that this can only be done
370 passes that need to traverse the program bottom-up on the call graph (callees
530 loop passes in its pipeline require. To make that easier,
698 Code generator passes are registered and initialized specially by
742 it is used and what it does. Here we discuss how and why passes are
745 As we saw above, passes are registered with the ``RegisterPass`` template. The
776 Specifying interactions between passes
780 passes interact with each other correctly. Because ``PassManager`` tries to
781 :ref:`optimize the execution of passes <writing-an-llvm-pass-passmanager>` it
782 must know how the passes interact with each other and what dependencies exist
783 between the various passes. To track this, each pass can declare the set of
784 passes that are required to be executed before the current pass, and the passes
788 computed before your pass is run. Running arbitrary transformation passes can
792 prerequisite passes, and invalidating **all** other passes.
807 information about which passes are required and not invalidated. To do this, a
815 LLVM has many different types of analyses and passes that can be required,
822 <aliasanalysis-chaining>` to other alias analysis passes. In cases where
832 For this reason, passes are allowed to declare that they preserve (i.e., they
835 affect the results of dominator analysis. By default, all passes are assumed
869 providing you with access to the passes that you declared that you required
916 Now that we understand the basics of how passes are defined, how they are used,
917 and how they are required from other passes, it's time to get a little bit
937 multiple different passes. Analysis Groups can be given human readable names
938 just like passes, but unlike passes, they need not derive from the ``Pass``
942 Analysis groups are used by client passes just like other passes are: the
945 <writing-an-llvm-pass-passmanager>` scans the available passes to see if any
948 :ref:`interaction between passes <writing-an-llvm-pass-interaction>` still
952 optional for normal passes, all analysis group implementations must be
985 human readable name provided for it. Unlike registration of passes, there is
993 Once the analysis is registered, passes can declare that they are valid
1035 designed to be an easy way to expose various success metrics from passes.
1047 passes, ensures their :ref:`prerequisites <writing-an-llvm-pass-interaction>`
1048 are set up correctly, and then schedules passes to run efficiently. All of the
1049 LLVM tools that run passes use the PassManager for execution of these passes.
1052 series of passes:
1063 #. **Pipeline the execution of passes on the program.** The ``PassManager``
1065 passes by pipelining the passes together. This means that, given a series
1070 function, etc... until the entire program has been run through the passes.
1081 information it has about the behaviors of the passes it is scheduling. For
1095 passes. Lets try it out with the gcse and licm passes:
1117 This output shows us when passes are constructed and when the analysis results
1129 passes.
1132 <writing-an-llvm-pass-basiccode>` pass in between the two passes:
1226 Registering dynamically loaded passes
1232 use some passes, while omitting others and maintain the flexibility to change
1257 passes. Here we will describe how to *register* a register allocator machine
1325 And finally, declare the command line option for your passes. Example:
1338 Using GDB with dynamically loaded passes
1341 Unfortunately, using GDB with dynamically loaded passes is not as easy as it
1427 of the semantics defined for passes above (specifically they cannot maintain
1433 This implementation would prevent each of the passes from having to implement
1437 Despite that, we have kept the LLVM passes SMP ready, and you should too.