similar to: [LLVMdev] Some thinking for callgraph builder

On Wed, 2006-05-24 at 11:04, Nai Xia wrote: > Indirect call information could be constructed either from partial result > of DSA as suggested by Andrew. And alternatively, it can use the alias > information constructed by any AA. I think both interface may be > provided to let clients chose between the generality and the tight > integration with wonderful DSA. I

Hi Chris, Oh, I can see that you very busy with nearly every topic on the list. Very hard working man :) Actually I am not in a hurry. And thanks in advance. I think LLVM gives me a platform to learn and exercise many things. Best wishes to LLVM , to you and anyone contributing to it. :) On Friday 26 May 2006 10:52, Chris Lattner wrote: > On Fri, 26 May 2006, Nai Xia wrote: > > Could

On Monday 22 May 2006 22:22, Andrew Lenharth wrote: > 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

On Tuesday 23 May 2006 13:34, Chris Lattner wrote: > On Tue, 23 May 2006, Nai Xia wrote: > > Maybe Chris can us give more helpful comments. > > Andrew (and Dinakar, and perhaps others) are the current current > maintainers of DSA. Oh, I'd say sorry to you and Andrew both. I had though you are the maintainer... ... So I am currently thinking that maybe it is not hard to

On Tue, 23 May 2006, Nai Xia wrote: > So I am currently thinking that maybe it is not hard to make the > callgraph more accurate in a similar way DSA deals with indirect > callsites. I am just curious about why it is not already in LLVM. I > think identifying the range of an indirect call is a worthwhile job, for > example if we want to track the correctness of a program's

On Tue, 2006-05-23 at 13:32 +0800, Nai Xia wrote: > On Monday 22 May 2006 22:22, Andrew Lenharth wrote: > > 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

On Tue, 23 May 2006, Nai Xia wrote: > Maybe Chris can us give more helpful comments. Andrew (and Dinakar, and perhaps others) are the current current maintainers of DSA. -Chris -- http://nondot.org/sabre/ http://llvm.org/

Hello, I am trying to apply DSA (from the poolalloc project - I'm on LLVM 3.2) on the following C program and found that the generated callgraph over-approximates the callees for the simple indirect call. #include <stdio.h> __attribute__((noinline)) static int f1(int arg1, int arg2) { return arg1 + arg2; } __attribute__((noinline)) static int run_func(int (*fptr)(int, int), int

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 !=

Thanks John. I guess I will use a ModulePass, so when I am implementing the “runOnModule” function, do I have to loop through all the functions, for each functions all the BasicBlocks and for each BasicBlock all the instructions or given the Module I have to call the CallGraph directly? Is there an example out there? I can’t find anything. Thanks. Simone > On Feb 24, 2015, at 13:29, John

I'm working on this issue, thank you for reporting it. The short answer is that the callgraph reported by TD is the same as discovered/computed during BU (and BU can't determine the indirect call can only target C2). I've added this example, and a few other related tests, to the DSA's test suite[1] to document this behavior while I'm working out what the best solution is.

On 2/25/15 10:51 AM, Simone Atzeni wrote: > Thanks John. > > I guess I will use a ModulePass, so when I am implementing the “runOnModule” function, > do I have to loop through all the functions, for each functions all the BasicBlocks and for each BasicBlock all the instructions If you know the Instruction, you can get it's basic block using Instruction::getParent(), and then get

Hi I see when LLVM builds the CallGraph SCCs. a function calling through a function pointer is conservatively assumed to call internal and external functions. Therefore, it has an edges pointing to the externalnode2, ie. the externalnode representing outgoing calls from this module. does LLVM have any function pointer analysis capabilities in the mainline ? Thanks, -Trent

Hi, I apologize if it is a rather stupid question, I am a newbie to LLVM. I notice a inconsistency between the current llvm1.6 doc and its source code. The doc states that the superclasses of GlobalVariable are GlobalValue, User, Value, however in the source code GlobalVariable has Constant as its super. I am just curious that why "variable" should be a subclass of "constant"?

Hello, I am trying to extract a callgraph using DSA, but the analysis looks quite pessimistic. I use TDD analysis and here is my test code: #include <stdlib.h> typedef void (*tX)(int a, int b); typedef void (*tY)(int a); typedef struct { tX p ; int n; } msg; static void A1(int a) { } static void B2(int a, int b) { } static void C2(int a, int b) { } tY q; static void decode(tX

Dear Simon, Kevin is correct; as far as I can tell, there is no method of getting the functions calling a given function. Instead, you have to start at the main() function and search for the function using a depth-first or breadth-first search. What may make sense is to build a new data structure that has nodes that point from callees to callers once and then use that for your queries.

Hi Chris, I took a haste look at the "Points-to Analysis in Almost Linear Time" by Steens , your PHD thesis and SteensGaard.cpp in LLVM this afternoon. So I think: 1. Actually the basic algorithm described originally by SteensGaard does not provide MOD/REF information for functions. 2. The context insensitive part of Data Structure Analysis (LocalAnalysis) can be deemed as an

Hi Simon, > From: Simone Atzeni <simone.at at gmail.com> > To: John Criswell <jtcriswel at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Walking thru CallGraph bottom up > Message-ID: <318EBA41-2040-4EFE-B330-5813C817C2A2 at gmail.com> > Content-Type: text/plain; charset="windows-1252" > > I think I got it and the example is

On Tuesday 16 May 2006 03:19, Chris Lattner wrote: > On Mon, 15 May 2006, Nai Xia wrote: > > > In other words, if I only use -steens-aa and the data_XXXs are all > > external global variables( and so inComplete ), > > Sounds right! > > > the call to printf will > > make the same effect, which I have tested it. > > > > Am I right ? :) >

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