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
212 contained in an anonymous namespace --- this reflects the fact that passes
269 nice command line option (:option:`--time-passes`) that allows you to get
270 information about the execution time of your pass along with the other passes
275 $ opt -load ../../../Debug+Asserts/lib/Hello.so -hello -time-passes < hello.bc > /dev/null
292 passes listed are automatically inserted by the :program:`opt` tool to verify
296 Now that you have seen the basics of the mechanics behind passes, we can talk
314 optimize how passes are run, so that the resultant compiler isn't unnecessarily
322 type is used for passes that do not have to be run, do not change state, and
345 A module pass can use function level passes (e.g. dominators) using the
348 not require any module or immutable passes. Note that this can only be done
374 passes that need to traverse the program bottom-up on the call graph (callees
694 Code generator passes are registered and initialized specially by
738 it is used and what it does. Here we discuss how and why passes are
741 As we saw above, passes are registered with the ``RegisterPass`` template. The
772 Specifying interactions between passes
776 passes interact with each other correctly. Because ``PassManager`` tries to
777 :ref:`optimize the execution of passes <writing-an-llvm-pass-passmanager>` it
778 must know how the passes interact with each other and what dependencies exist
779 between the various passes. To track this, each pass can declare the set of
780 passes that are required to be executed before the current pass, and the passes
784 computed before your pass is run. Running arbitrary transformation passes can
788 prerequisite passes, and invalidating **all** other passes.
803 information about which passes are required and not invalidated. To do this, a
811 LLVM has many different types of analyses and passes that can be required,
818 <aliasanalysis-chaining>` to other alias analysis passes. In cases where
828 For this reason, passes are allowed to declare that they preserve (i.e., they
831 affect the results of dominator analysis. By default, all passes are assumed
865 providing you with access to the passes that you declared that you required
912 Now that we understand the basics of how passes are defined, how they are used,
913 and how they are required from other passes, it's time to get a little bit
933 multiple different passes. Analysis Groups can be given human readable names
934 just like passes, but unlike passes, they need not derive from the ``Pass``
938 Analysis groups are used by client passes just like other passes are: the
941 <writing-an-llvm-pass-passmanager>` scans the available passes to see if any
944 :ref:`interaction between passes <writing-an-llvm-pass-interaction>` still
948 optional for normal passes, all analysis group implementations must be
981 human readable name provided for it. Unlike registration of passes, there is
989 Once the analysis is registered, passes can declare that they are valid
1031 designed to be an easy way to expose various success metrics from passes.
1043 passes, ensures their :ref:`prerequisites <writing-an-llvm-pass-interaction>`
1044 are set up correctly, and then schedules passes to run efficiently. All of the
1045 LLVM tools that run passes use the PassManager for execution of these passes.
1048 series of passes:
1059 #. **Pipeline the execution of passes on the program.** The ``PassManager``
1061 passes by pipelining the passes together. This means that, given a series
1066 function, etc... until the entire program has been run through the passes.
1077 information it has about the behaviors of the passes it is scheduling. For
1091 passes. Lets try it out with the gcse and licm passes:
1113 This output shows us when passes are constructed and when the analysis results
1125 passes.
1128 <writing-an-llvm-pass-basiccode>` pass in between the two passes:
1222 Registering dynamically loaded passes
1228 use some passes, while omitting others and maintain the flexibility to change
1253 passes. Here we will describe how to *register* a register allocator machine
1321 And finally, declare the command line option for your passes. Example:
1334 Using GDB with dynamically loaded passes
1337 Unfortunately, using GDB with dynamically loaded passes is not as easy as it
1423 of the semantics defined for passes above (specifically they cannot maintain
1429 This implementation would prevent each of the passes from having to implement
1433 Despite that, we have kept the LLVM passes SMP ready, and you should too.