Lines Matching full:passes

49 Adding Passes to a Pass Manager
56 can only contain function passes:
116 Generally you want to group CGSCC/function/loop passes together in a pass
141 module, then run both passes on the second function in the module, and so on.
144 of optimization. For example, running all loop passes on a loop may cause a
148 Inserting Passes into Default Pipelines
151 Rather than manually adding passes to a pass manager, the typical way of
156 Sometimes either frontends or backends will want to inject passes into the
158 backends may want to add passes that lower custom intrinsics. For these
159 cases, ``PassBuilder`` exposes callbacks that allow injecting passes into
172 ``PassBuilder`` for the various places that passes can be added.
176 backend to inject passes into the pipeline.
179 sanitizer) passes to various parts of the pipeline.
181 backend adding passes to various parts of the pipeline.
183 Pass plugins can also add passes into default pipelines. Different tools have
191 LLVM provides many analyses that passes can use, such as a dominator tree.
206 passes which work on a fixed scope. However, some passes want to peek up or
235 IR passes can result in quadratic compile time behavior. For example, a module
236 analysis often scans every function and allowing function passes to run a module
237 analysis may cause us to scan functions a quadratic number of times. If passes
241 there isn't infrastructure for this (aside from function analyses in loop passes
248 example parallelizing function passes over different functions in a CGSCC or
249 module. Since passes can ask for a cached analysis result, allowing passes to
253 inner level IR. Outer analyses unused by inner passes can and often will be
259 function analyses in loop passes. Loop passes often use function analyses such
260 as the dominator tree. Loop passes inherently require modifying the function the
264 make sure the function analyses that loop passes use are valid, they are
265 manually updated in the loop passes to ensure that invalidation is not
266 necessary. There is a set of common function analyses that loop passes and
267 analyses have access to which is passed into loop passes as a
269 not accessible from loop passes.
427   $ opt -passes='pass1,pass2' /tmp/a.ll -S
428   # -p is an alias for -passes
437   $ opt -passes='function(no-op-function),no-op-module' /tmp/a.ll -S
444 …$ opt -passes='no-op-module,cgscc(no-op-cgscc,function(no-op-function,loop(no-op-loop))),function(…
450   $ opt -passes='no-op-function,no-op-module' /tmp/a.ll -S
464   $ opt -passes='no-op-function,no-op-function' /tmp/a.ll -S
465   $ opt -passes='function(no-op-function,no-op-function)' /tmp/a.ll -S
474   $ opt -passes='no-op-function,no-op-loop' /tmp/a.ll -S
475   $ opt -passes='no-op-function,loop(no-op-loop)' /tmp/a.ll -S
477 For a list of available passes and analyses, including the IR unit (module,
482   $ opt --print-passes
494   $ opt -passes='function(require<my-function-analysis>),my-module-pass' /tmp/a.ll -S
506 Some IR passes are considered part of the backend codegen pipeline even if
507 they are LLVM IR passes (whereas all MIR passes are codegen passes). This
512 legacy PM with passes on a per target basis has been removed. It was mainly