I am writing a ModulePass and invoke it using opt -load. I would require that alloca has been promoted to registers when my pass runs, using the -mem2reg switch for opt.
There is a link which indicates that the PromoteMemoryToRegsiter pass is a transform pass and as such should not be required by my pass. That's a statement from 2010. Does that still hold?
One of the posts I found suggested something like
AU.addRequiredID(PromoteMemoryToRegister::MemoryToRegisterID);
but that contradicted the post I linked above.
So my question is, how to I express this dependency for my pass, if possible? How do I express, in general, such pass dependencies? And what's the difference between a transform pass and, well, another pass?
What's the difference between a transform pass and another pass?
A transform pass is a pass that may invalidate the results of other passes.
How to I express this dependency for my pass?
First of all, I recommend reading the pass-dependency section of the official "how to write a pass" guide. In any case, the correct way to add a dependency between transformation passes is to add one before the other in your pass manager (see the guide section on the pass manager), or, if you just invoke opt, then add all the passes you want in the order you want them to occur, e.g.:
opt -load mypass.so -mem2reg -mypass
Related
Is it possible to apply LLVM transformation pass to a specific basic block, instead of the whole IR?
I know how to apply a pass to the whole IR:
$ opt –S –instcombine test.ll –o out.ll
But there might be several basic blocks inside test.ll and I want to apply –instcombine to just one of them.
Generally, no. Some LLVM passes are written to work on whole modules, others on whole functions. Some are also safe to use for single basic blocks (more by chance than by design), but LLVM's pass interface deals with only the design unit (functions in case of function passes, modules in case of module passes). That is, function passes are given a function by the pass manager, and nothing else.
I need to tell the pass to look out for a specific function in the file. And I want to specify which function to look out for 'on the go' i.e when I run the pass. Any idea how I can do that? It's sort of like passing arguments to a function in theory.
Add a command line option using cl::opt<string> and set it when running your pass.
Alternatively, if you are producing an IR from C or C++ using clang, you can utilize __attribute((__annotate__(("foo")))) to mark functions you are interested in.
I want to remove phi nodes from my llvm IR files, so I've read that Reg2Mem pass is a solution (why?).
I can easily use this pass from the opt tool by specifying -reg2mem as argument.
However, I want this functionality be built into my own pass called FlattenO. Therefore, I try to add the Reg2Mem pass as a required dependency of my pass (it should be called automatically then?).
void FlattenO::getAnalysisUsage(AnalysisUsage &AU) const {
AU.addRequired<Reg2Mem>();
}
The code above doesn't work, because it cannot find any Reg2Mem pass. What files should I include to use the Reg2Mem pass? Also, please correct my code, so everything should work as intended.
Is there any document on the list of Analysis and Transform passes available for use in the AnalysisUsage::addRequired<> and Pass::geAnalysis<> functions?
I can get a list of passes in http://llvm.org/docs/Passes.html, but it only shows the command line names for the passes. How can I know the underlying pass classes?
Not really, no. Just look at the source. The header files in include/llvm/Analysis/ and include/llvm/Transforms/ will tell you everything you need to know.
Moreover, grepping over the source for getAnalysis< will tell you which passes are used as analyses inside the LLVM source code.
I want to apply a DFS traversing algorithm on a CFG of a function. Therefore, I need the internal representation of the CFG. I need oriented edges and spotted MachineBasicBlock::const_succ_iterator. It is there a way to get the CFG with oriented edges by using a FunctionPass, instead of a MachineFunctionPass? The reason why I want this is that I have problems using MachineFunctionPass. I have written several complex passes till now, but I cannot run a MachineFunctionPass pass.
I found that : "A MachineFunctionPass is a part of the LLVM code generator that executes on the machine-dependent representation of each LLVM function in the program. Code generator passes are registered and initialized specially by TargetMachine::addPassesToEmitFile and similar routines, so they cannot generally be run from the opt or bugpoint commands."...So how I can run a MachineFunctionPass?
When I was trying to run with opt a simple MachineFunctionPass, I got the error :
Pass 'mycfg' is not initialized.
Verify if there is a pass dependency cycle.
Required Passes:
opt: PassManager.cpp:638: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion `PI && "Expected required passes to be initialized"' failed.
So I have to initialize the pass. But in my all other passes I did not any initialization and I don't want to use INITIALIZE_PASS since I have to recompile the llvm file that is keeping the pass registration... Is there a way to keep using static RegisterPass for a MachineFunctionPass ? I mention that if I change to FunctionPass, I have no problems, so indeed it might be an opt problem.
I have started another pass for CallGraph. I am using CallGraph &CG = getAnalysis<CallGraph>(); efficiently. It is a similar way of getting CFG-s? What I found till now are succ_iterator/succ_begin/succ_end which are from CFG.h, but I think I still have to get the CFG analysis somehow.
Thank you in advance !
I think you may have some terms mixed up. Basic blocks within each function are already arranged in a kind-of CFG, and LLVM provides you the tools to traverse that. See my answer to this question, for example.
MachineFunction lives on a different level, and unless you're doing something very special, this is not the level you should operate on. It's too low-level, and too target specific. There's some overview of the levels here