Lines Matching full: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
212 contained in an anonymous namespace --- this reflects the fact that passes
270 nice command line option (:option:`--time-passes`) that allows you to get
271 information about the execution time of your pass along with the other passes
276 $ opt -load ../../../Debug+Asserts/lib/Hello.so -hello -time-passes < hello.bc > /dev/null
293 passes listed are automatically inserted by the :program:`opt` tool to verify
297 Now that you have seen the basics of the mechanics behind passes, we can talk
315 optimize how passes are run, so that the resultant compiler isn't unnecessarily
323 type is used for passes that do not have to be run, do not change state, and
346 A module pass can use function level passes (e.g. dominators) using the
349 not require any module or immutable passes. Note that this can only be done
375 passes that need to traverse the program bottom-up on the call graph (callees
696 Code generator passes are registered and initialized specially by
740 it is used and what it does. Here we discuss how and why passes are
743 As we saw above, passes are registered with the ``RegisterPass`` template. The
774 Specifying interactions between passes
778 passes interact with each other correctly. Because ``PassManager`` tries to
779 :ref:`optimize the execution of passes <writing-an-llvm-pass-passmanager>` it
780 must know how the passes interact with each other and what dependencies exist
781 between the various passes. To track this, each pass can declare the set of
782 passes that are required to be executed before the current pass, and the passes
786 computed before your pass is run. Running arbitrary transformation passes can
790 prerequisite passes, and invalidating **all** other passes.
805 information about which passes are required and not invalidated. To do this, a
813 LLVM has many different types of analyses and passes that can be required,
820 <aliasanalysis-chaining>` to other alias analysis passes. In cases where
830 For this reason, passes are allowed to declare that they preserve (i.e., they
833 affect the results of dominator analysis. By default, all passes are assumed
867 providing you with access to the passes that you declared that you required
914 Now that we understand the basics of how passes are defined, how they are used,
915 and how they are required from other passes, it's time to get a little bit
935 multiple different passes. Analysis Groups can be given human readable names
936 just like passes, but unlike passes, they need not derive from the ``Pass``
940 Analysis groups are used by client passes just like other passes are: the
943 <writing-an-llvm-pass-passmanager>` scans the available passes to see if any
946 :ref:`interaction between passes <writing-an-llvm-pass-interaction>` still
950 optional for normal passes, all analysis group implementations must be
963 Passes that use the `AliasAnalysis
983 human readable name provided for it. Unlike registration of passes, there is
991 Once the analysis is registered, passes can declare that they are valid
1033 designed to be an easy way to expose various success metrics from passes.
1045 passes, ensures their :ref:`prerequisites <writing-an-llvm-pass-interaction>`
1046 are set up correctly, and then schedules passes to run efficiently. All of the
1047 LLVM tools that run passes use the PassManager for execution of these passes.
1050 series of passes:
1061 #. **Pipeline the execution of passes on the program.** The ``PassManager``
1063 passes by pipelining the passes together. This means that, given a series
1068 function, etc... until the entire program has been run through the passes.
1079 information it has about the behaviors of the passes it is scheduling. For
1093 passes. Lets try it out with the gcse and licm passes:
1115 This output shows us when passes are constructed and when the analysis results
1127 passes.
1130 <writing-an-llvm-pass-basiccode>` pass in between the two passes:
1224 Registering dynamically loaded passes
1230 use some passes, while omitting others and maintain the flexibility to change
1255 passes. Here we will describe how to *register* a register allocator machine
1306 declaration to ``Passes.h`` and add a "pseudo" call line to
1323 And finally, declare the command line option for your passes. Example:
1336 Using GDB with dynamically loaded passes
1339 Unfortunately, using GDB with dynamically loaded passes is not as easy as it
1425 of the semantics defined for passes above (specifically they cannot maintain
1431 This implementation would prevent each of the passes from having to implement
1435 Despite that, we have kept the LLVM passes SMP ready, and you should too.
