search for: fpass

...o AFAIK no, you should get the order you specified on the command line, i.e. > > 1. mymodulepass0 > 2. myfunctionpass on each function > 3. mymodulepass1 MMMh, from opt.cpp, there's a first call to: if (OptLevelO1 || OptLevelO2 || OptLevelOs || OptLevelOz || OptLevelO3) { FPasses->doInitialization(); for (Function &F : *M) FPasses->run(F); FPasses->doFinalization(); } then a few lines later, a call to: Passes.run(*M); where Passes is the Module pass Manager and FPasses is the Function Pass Manager. Each is filled in AddOptimizationPasse...

...inline) is followed by function passes that preserve the callgraph, then it should schedule them together like above. However if the SCC pass is followed by a function pass that does not preserve the callgraph then it should be scheduled entirely after the SCC pass. For example, imagine -inline -fpass -loop-unswitch, where fpass is a function pass that preserves the callgraph. Then the pass manager should do: run -inline on G run -fpass on G run -inline on F run -fpass on F run -loop-unswitch on G run -loop-unswitch on F. Just my opinion of course. Ciao, Duncan. > So are loop passed *...

I'm looking at bug 3367. If I run: $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions ... it eventually crashes in the inliner, because the call graph isn't up to date. (NB if you want to reproduce this you'll have to apply my patch from bug 3367 first.) The reason the call graph isn't up to date is that -loop-unswitch has changed a function and not updated

...n passes that preserve the callgraph, then it should > schedule > them together like above. However if the SCC pass is followed by a > function pass that does not preserve the callgraph then it should be > scheduled entirely after the SCC pass. > > For example, imagine -inline -fpass -loop-unswitch, where fpass is a > function pass that preserves the callgraph. Then the pass manager > should do: > > run -inline on G > run -fpass on G > run -inline on F > run -fpass on F > run -loop-unswitch on G > run -loop-unswitch on F. This will defeat the goal o...

On Mon, May 09, 2016 at 01:07:07PM -0700, Mehdi Amini via llvm-dev wrote: > > > On May 9, 2016, at 10:43 AM, Ricardo Nobre via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > I'm a PhD student doing phase ordering as part of my PhD topic and I would like to ask some questions about LLVM. > > > > Executing the following

...BBPassUnit::BBPass(Pass) {} +}; + +class LPassUnit : public PassUnit { + LoopPass *LPass; + +public: + LPassUnit(Traversal traversal = LINEAR, LoopPass *Pass) : + PassUnit::traversal(traversal), + PassUnit::Pass(static_cast<Pass*>(Pass)) + LPassUnit::LPass(Pass) {} +}; + +class FPassUnit : public PassUnit { + FunctionPass *FPass; + +public: + FPassUnit(Traversal traversal = LINEAR, FunctionPass *Pass) : + PassUnit::traversal(traversal), + PassUnit::Pass(static_cast<Pass*>(Pass)) + FPassUnit::FPass(Pass) {} +}; + +// For CallGraphSCC passes, really they'r...

The patch below basically hammers out some ideas as to where I'd like to take the passmanager in LLVM. I've tried thinking things through, but I'm still a n00b, so some criticism would be more than welcome. =) Starting from line 191 down. If you're wondering why I created a patch, well that's because I found thinking in passmanagert.h the most productive. -- Regards.

...Unit : public PassUnit { > + LoopPass *LPass; > + > +public: > + LPassUnit(Traversal traversal = LINEAR, LoopPass *Pass) : > + PassUnit::traversal(traversal), > + PassUnit::Pass(static_cast<Pass*>(Pass)) > + LPassUnit::LPass(Pass) {} > +}; > + > +class FPassUnit : public PassUnit { > + FunctionPass *FPass; > + > +public: > + FPassUnit(Traversal traversal = LINEAR, FunctionPass *Pass) : > + PassUnit::traversal(traversal), > + PassUnit::Pass(static_cast<Pass*>(Pass)) > + FPassUnit::FPass(Pass) {} > +}; > + >...