similar to: [LLVMdev] setPreservesCFG

On Feb 23, 2009, at 1:23 PM, John Criswell wrote: > Dear All, > > Does the setPreservesCFG() call for passes indicate that the CFG in > the > local function does not change or that the global CFG does not change? The CFG in this context is just the per-function CFG. "setPreservesCFG" can only be used meaninfully for FunctionPasses. > In other words, can a pass

Hi Michael, > InstCombine says in its getAnalysisUsage that it preserves the CFG, > but for the 4th argument in its INITIALIZE_PASS call, it says false, > which I believe corresponds to whether it preserves the CFG. that argument should be set to true if the pass only looks at the CFG, i.e. whatever it computes/does is only a function of the CFG, and doesn't otherwise depend on what

InstCombine says in its getAnalysisUsage that it preserves the CFG, but for the 4th argument in its INITIALIZE_PASS call, it says false, which I believe corresponds to whether it preserves the CFG. Is this a mistake, or is there deeper meaning here? InstructionCombining.cpp:73-82 char InstCombiner::ID = 0; INITIALIZE_PASS(InstCombiner, "instcombine", "Combine

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works

If I run: opt -globals-aa -die -inline -debug-pass=Details foo.ll -S then I will get this pass structure: Target Library Information Target Transform Information Target Pass Configuration Assumption Cache Tracker Profile summary info ModulePass Manager CallGraph Construction Globals Alias Analysis FunctionPass Manager BasicBlockPass Manager Dead Instruction

Hello, I have created a ModulePass, that now needs LoopInfo information. The ModulePass registration is taken from [1]. I use clang to directly invoke it (This is also a hard requirement, because I need the fancy output of clang warnings/remarks). The problem is, that the dependency to the LoopInfoWrapperPass does not seem to work. The error is: --- snip --- clang-4.0:

I'm not sure about the old pass manager, but I think the new pass manager solves this issue. See llvm::updateCGAndAnalysisManagerForFunctionPass where it updates the call graph to be in sync with edges deleted by function passes. So I suspect the right fix is to use the new pass manager. -- Sanjoy On Mon, May 7, 2018 at 7:32 AM, Björn Pettersson A via llvm-dev <llvm-dev at

Just noticed that quite a few passes like LoopSimplify are implemented in a single .cpp file ... this makes it impossible to specify LoopSimplify using the "addRequired" method. Was there any particular reason to do it this way? I wouldn't mind doing the splitting myself, though I am not using the CVS versions right now. Also, it would be nice to have support for some sort of a

Well, do you have a patch that enables the new pass manager that we can land then? To be more serious: 1) I don't even know how to run those passes using the new pass manager even if it where enabled by default. I guess that I'm supposed to use -passes. Is there a syntax description for that option somewhere? How do I for example run -die? 2) "Use the new pass manager" does

Hi! On 12/03/2009 07:50 PM, Dan Gohman wrote: > Hello, > > Here are a few misc. comments on this patch. > > Would it make sense to mark the ProfileInfo passes as "CFGOnly?" > If so, that would let them be automatically preserved by passes > which don't modify the CFG (and that call AU.setPreservesCFG()). Yes, it would, how do I do this? :-) >> +

Hello, Here are a few misc. comments on this patch. Would it make sense to mark the ProfileInfo passes as "CFGOnly?" If so, that would let them be automatically preserved by passes which don't modify the CFG (and that call AU.setPreservesCFG()). > + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { > + PI->splitEdge(OrigPreHeader, NewHeader,

Hi Björn, 1) The pass pipeline syntax is documented here: https://github.com/llvm-project/llvm/blob/master/include/llvm/Passes/PassBuilder.h#L378 -die is not implemented, since the new pass manager does not support BasicBlock passes. But you can use dce instead: "-passes=dce" 2) I don't have a qualified answer here, but if I recall correctly, the trouble to correctly update the

Thank you for your reply Yes, I change them, so what should I do for another loops? On Mon, Dec 12, 2011 at 7:54 PM, neda 8664 <neda8664 at gmail.com> wrote: > Thank you for your reply > > Yes, I change them, so what should I do for another loops? > > On Mon, Dec 12, 2011 at 7:42 PM, John Criswell <criswell at illinois.edu>wrote: > >> On 12/12/11 9:59 AM,

On 12/12/11 10:25 AM, neda 8664 wrote: > > Thank you for your reply > > Yes, I change them, so what should I do for another loops? I don't really know what you should do since I don't know what your code does. All I know is that it's changing the function's control-flow graph. If you're not modifying the structure of the loops in the function, then you can

On 5/6/15 11:15 AM, Kuperstein, Michael M wrote: > > I’ve always thought that the only guarantee is that > doFinalization(Module &M) runs after runOnFunction() was executed for > all functions in M, and there’s no guarantee it runs *immediately* after. > > That is, a PM may run a bunch of function passes over each function, > and only then call doFinazliation() for each

So I got very mixed results. With the CallGraphSCCPass, both `addRequired<DominatorTreeWrapperPass>` and `addRequired<MemoryDependenceAnalysis>` fail at runtime. The LLVM core has just two CallGraphSCCPasses and neither uses neither analyses, so it's hard to find a valid example. I transformed the pass into a ModulePass, using scc_iterator as shown in CGPassManager to process

Thanks John. Does this solve the problem of analysis availability though? If I still have to run the function analyses manually, I might as well keep rolling with the CallGraphSCCPass. (I probably should have mentioned that this is what I’m using right now.) Félix > Le 2015-05-19 à 10:12:32, John Criswell <jtcriswel at gmail.com> a écrit : > > On 5/18/15 10:45 PM, Félix Cloutier

On 6/5/12 10:39 AM, Ralf Karrenberg wrote: > Hi John, > > On 6/5/12 4:31 PM, John Criswell wrote: >> On 4/12/12 3:32 AM, Ivan Llopard wrote: >>> Hi again, >>> >>> I come back to this issue with an example. It's a pass which does >>> nothing but throw the 'Unable to schedule' error. >>> >>> namespace { >>>

On Fri, 29 Apr 2005, Sameer D. Sahasrabuddhe wrote: > Just noticed that quite a few passes like LoopSimplify are implemented > in a single .cpp file ... this makes it impossible to specify > LoopSimplify using the "addRequired" method. Was there any particular > reason to do it this way? I wouldn't mind doing the splitting myself, > though I am not using the CVS

On 5/6/15 10:19 AM, Kuperstein, Michael M wrote: > > Hello Cristiano, > > I don’t think doFinalization() is really meant to be used this way. > My understanding is that doInitialization() and doFinalization() are designed specifically for modifying the LLVM IR (otherwise, why would a mutable reference to the Function be provided)? If that is not the case, then there is either a