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
210 contained in an anonymous namespace --- this reflects the fact that passes
267 nice command line option (:option:`--time-passes`) that allows you to get
268 information about the execution time of your pass along with the other passes
273 $ opt -load lib/LLVMHello.so -hello -time-passes < hello.bc > /dev/null
289 passes listed are automatically inserted by the :program:`opt` tool to verify
293 Now that you have seen the basics of the mechanics behind passes, we can talk
311 optimize how passes are run, so that the resultant compiler isn't unnecessarily
319 type is used for passes that do not have to be run, do not change state, and
342 A module pass can use function level passes (e.g. dominators) using the
345 not require any module or immutable passes. Note that this can only be done
371 passes that need to traverse the program bottom-up on the call graph (callees
531 loop passes in its pipeline require. To make that easier,
699 Code generator passes are registered and initialized specially by
743 it is used and what it does. Here we discuss how and why passes are
746 As we saw above, passes are registered with the ``RegisterPass`` template. The
777 Specifying interactions between passes
781 passes interact with each other correctly. Because ``PassManager`` tries to
782 :ref:`optimize the execution of passes <writing-an-llvm-pass-passmanager>` it
783 must know how the passes interact with each other and what dependencies exist
784 between the various passes. To track this, each pass can declare the set of
785 passes that are required to be executed before the current pass, and the passes
789 computed before your pass is run. Running arbitrary transformation passes can
793 prerequisite passes, and invalidating **all** other passes.
808 information about which passes are required and not invalidated. To do this, a
816 LLVM has many different types of analyses and passes that can be required,
823 <aliasanalysis-chaining>` to other alias analysis passes. In cases where
833 For this reason, passes are allowed to declare that they preserve (i.e., they
836 affect the results of dominator analysis. By default, all passes are assumed
870 providing you with access to the passes that you declared that you required
917 Now that we understand the basics of how passes are defined, how they are used,
918 and how they are required from other passes, it's time to get a little bit
938 multiple different passes. Analysis Groups can be given human readable names
939 just like passes, but unlike passes, they need not derive from the ``Pass``
943 Analysis groups are used by client passes just like other passes are: the
946 <writing-an-llvm-pass-passmanager>` scans the available passes to see if any
949 :ref:`interaction between passes <writing-an-llvm-pass-interaction>` still
953 optional for normal passes, all analysis group implementations must be
986 human readable name provided for it. Unlike registration of passes, there is
994 Once the analysis is registered, passes can declare that they are valid
1036 designed to be an easy way to expose various success metrics from passes.
1048 passes, ensures their :ref:`prerequisites <writing-an-llvm-pass-interaction>`
1049 are set up correctly, and then schedules passes to run efficiently. All of the
1050 LLVM tools that run passes use the PassManager for execution of these passes.
1053 series of passes:
1064 #. **Pipeline the execution of passes on the program.** The ``PassManager``
1066 passes by pipelining the passes together. This means that, given a series
1071 function, etc... until the entire program has been run through the passes.
1082 information it has about the behaviors of the passes it is scheduling. For
1096 passes. Lets try it out with the gvn and licm passes:
1119 This output shows us when passes are constructed.
1126 once, and shared by three passes.
1129 <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.