search for: basiccallgraph

Hi, I did a little experiment, basically to extract implemented CallGraph to be a "new" pass with different registered name, and run the "new" pass, but the result always gives out Segmentation Fault... I am probably missing sth? Implemented another new class, class BasicCallGraph2 : public ModulePass, public CallGraph { ..... ... } The inside code is exact same as BasicCallGraph, except registered passname to be testcgn and the information of the pass. then after enabling and run the new pass, on a test.bc file, there is always a segmentation fault. 0 libLLVM-2.7.so.1 0x0...

...eriment, basically to extract implemented CallGraph > to be a "new" pass with different registered name, and run the "new" > pass, but the result always gives out Segmentation Fault... I am > probably missing > sth? > > Implemented another new class, > class BasicCallGraph2 : public ModulePass, public CallGraph { > ..... > ... > } > The inside code is exact same as BasicCallGraph, except registered > passname to be testcgn and the information of the pass. then after > enabling and run the new pass, on a test.bc file, there is always a > segmentat...

On Thu, 12 Jul 2007, Zhongxing Xu wrote: > The current BasicCallGraph will miss call sites like this: > %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( ) > ; <i8*> [#uses=1] > > Here the direct user of @find_ispell is a ConstantExpr. > I added several lines of code to address this case. > Below is the output of comma...

The current BasicCallGraph will miss call sites like this: %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( ) ; <i8*> [#uses=1] Here the direct user of @find_ispell is a ConstantExpr. I added several lines of code to address this case. Below is the output of command: svn diff lib/Analysis/IPA...

...ending on what you are doing, using the LLVM IR can be tricky for this sort of stuff because it can get too far from the source level. -Chris > On 7/17/07, Chris Lattner <sabre at nondot.org> wrote: >> >> On Thu, 12 Jul 2007, Zhongxing Xu wrote: >> > The current BasicCallGraph will miss call sites like this: >> > %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( ) >> > ; <i8*> [#uses=1] >> > >> > Here the direct user of @find_ispell is a ConstantExpr. >> > I added several lines of code to ad...

...times generates this kind of call instruction, which cause the call graph to be incomplete. But thanks for your information, instcombine really solves the problem. On 7/17/07, Chris Lattner <sabre at nondot.org> wrote: > > On Thu, 12 Jul 2007, Zhongxing Xu wrote: > > The current BasicCallGraph will miss call sites like this: > > %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( ) > > ; <i8*> [#uses=1] > > > > Here the direct user of @find_ispell is a ConstantExpr. > > I added several lines of code to address this case. > &gt...

> Happy to help. You'll probably find that other optimizations help as > well, such as simplifycfg (which deletes dead blocks). Thank you. I am using it. Depending on what > you are doing, using the LLVM IR can be tricky for this sort of stuff > because it can get too far from the source level. > Yes, it is really a problem. Now I am using my eyes to map the LLVM IR back

...some > strange errors in LLVM Passes that use analysis groups and multiple > inheritance. Hey John, This is almost certainly due to the "eliminate rtti" work. You probably need to implement "getAdjustedAnalysisPointer" methods in your passes, see BasicAliasAnalysis or BasicCallGraph as examples. -Chris > > To create analysis groups in LLVM 2.6, I would first create a base class > for the analysis group and then another class that inherited from both > ModulePass and the analysis group base class. That worked in LLVM 2.6, > but now in LLVM 2.7 I'm gett...

...ourself: find all load/store > > instructions with its destination is function type. > > You may want to look at how the call graph builder works. It finds all > indirect call sites, and also finds all functions whose address escapes > (this is, may be called indirectly). The BasicCallGraph class only lines out the indirect calls(makes the caller point to external node), but do not resolves them using alias analysis such as DSA. I think DSA solve this problem for interested call sites by finding the corresponding globals(i.e. the functions) for the callsite DSnode. Maybe 夏一民 just w...

...gt; > instructions with its destination is function type. > > > > You may want to look at how the call graph builder works. It finds all > > indirect call sites, and also finds all functions whose address escapes > > (this is, may be called indirectly). > > The BasicCallGraph class only lines out the indirect calls(makes the caller point to external node), > but do not resolves them using alias analysis such as DSA. > I think DSA solve this problem for interested call sites by finding the corresponding globals(i.e. the functions) > for the callsite DSnode. M...

Dear All, I'm currently upgrading SAFECode to the LLVM 2.7 API. I'm getting some strange errors in LLVM Passes that use analysis groups and multiple inheritance. To create analysis groups in LLVM 2.6, I would first create a base class for the analysis group and then another class that inherited from both ModulePass and the analysis group base class. That worked in LLVM 2.6, but

Михаил wrote: > It is ModulePass with AnalysisUsage of CallGraph Ah, then you'll need to update the CallGraph first. Use "CG.removeFunctionFromModule(F);" before deleting it. Nick > Yours sincerely, > Kadysev Mikhail > > 22.04.2012, в 5:20, Nick Lewycky написал(а): > >> Михаил wrote: >>> Thanks, but I replaceAllUsesWith() - works well, but I still

It is ModulePass with AnalysisUsage of CallGraph Yours sincerely, Kadysev Mikhail 22.04.2012, в 5:20, Nick Lewycky написал(а): > Михаил wrote: >> Thanks, but I replaceAllUsesWith() - works well, but I still get bug in >> eraseFromParent(): >> >> While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi >> An asserting value handle still pointed to this value! >>

On 5/10/09, Török Edwin <edwintorok at gmail.com> wrote: > On 2009-05-10 20:11, Nick Johnson wrote: > > Hello, > > > > I'm writing a Function Pass. This function pass needs access to the > > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph > > information without changing my pass to a CallGraphSCCPass ? > > > Does

...a CallGraphSCCPass ? >> >> >> Does getAnalysis<CallGraph>() work? >> >> > AFAIK, it's not a pass. > > It is, see lib/Analysis/IPA/CallGraph.cpp: static RegisterAnalysisGroup<CallGraph> X("Call Graph"); static RegisterPass<BasicCallGraph> Y("basiccg", "Basic CallGraph Construction", false, true); static RegisterAnalysisGroup<CallGraph, true> Z(Y); I know that using getAnalysis<CallGraph> works in a ModulePass, but never tried it in a FunctionPass. >> But I'm not sure if using a Functi...

On Mon, 2006-05-22 at 15:33 +0800, 夏一民 wrote: > But my code does not always works: if the arguments are not pointer, > CompleteBUDataStructures not records it. So, if you want to find all indirect > calls, you maybe have to repair CompleteBUDataStructures. :) Not surprising, CBU is trying to do something entirely different that what you are. > If you do not use BUDataStructures, you

>On Monday 22 May 2006 22:22, Andrew Lenharth wrote: > The BasicCallGraph class only lines out the indirect calls(makes the caller point to external node), >but do not resolves them using alias analysis such as DSA. >I think DSA solve this problem for interested call sites by finding the corresponding globals(i.e. the functions) >for the callsite DSnode. Ye...

The follwing is a snippet of code to find some indirect calls in a module, which I learned from TopDownClosure.cpp: void FPS::repairCallGraph(Module &M) { CompleteBUDataStructures &DS = getAnalysis<CompleteBUDataStructures>(); for (Module::iterator f = M.begin(); f != M.end(); ++f ) { if( f->isExternal() ) continue; for (Function::iterator I = f->begin(); I !=

I printed the call graph as you suggested. The bugpoint bytecode that I sent below prints the following call graph: Indirect call node / | | \ / | | \ V | V V execute | prog_char clear_func | | V V push_constant | V Node0x8d7b370 i.e., Indirect call node -> execute