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 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 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 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/

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"?

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

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 ? :) >

On Wed, 17 May 2006, Nai Xia wrote: > Unfortunately, I did not locate the lines in steens-aa for "printf" special case. > In ds-aa, I found the lines below: Right, steens-aa and ds-aa share code for "local analysis", they just stitch it together into an interprocedural analysis in different ways. The code below is used for steens-aa. >

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 ? :) If you've tested it then, yes you're right :). I haven't played with this stuff for a long time,

Hi, I am using LLVM to compile vsftp to native x86 ELF code. One of it's object file (sysdeputil) contains inline asm so cannot be compiled by gcc-3.4 frontend. So I decided to firstly link together the llvm objects and libcrtend and compile it to native .o file and then link it with sysdeputil.o . The Makefile is sth like this: vsftpd: $(OBJS) gccld -r -native -o vsftpd.o $(OBJS)

Hi, I have tried another way: ar rcs libsysdeputil.a sysdeputil.o gccld seems to recognize the file type. However, it stills find unresoved symbols which are actually the functions in sysdeputil.o (can be find out with `nm libsysdeputil.a`) The problem disappears if native gcc/ld tool chain is used. As another test, main.c: ----------------- extern void foo(); int main() { foo(); return

In a code segment of my pass plugin, I try to gather AliasSets for all StoreInst, LoadInst and CallInst instructions in a function. Some behaviors of the pass puzzled me. Below is the *.ll of the test program which I run the pass on, it was get with "llvm-gcc -Wl,--disable-opt" from a rather simple *.c program. ---------------------------------- ; ModuleID = 'ptralias.bc'

Nia, I improved the documentation with this patch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20060410/034012.html You can read it online, here: http://llvm.org/docs/ProgrammersManual.html#GlobalVariable Please let me if you need further explanation in the documentation. Reid. On Fri, 2006-04-14 at 18:19 +0800, Nai Xia wrote: > Hi, > I apologize if it is a rather stupid

Oh, I appologize that I should not have asked about __main() ---- it appears in FAQ. But the question remains that why call to __main() can alias stack location? I think the memory location pointed by data_X pointers are not visible to __main(). In comparison, calls to printf() do not have similar effect. On 5/14/06, Nai Xia <nelson.xia at gmail.com> wrote: > > In a code segment of

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

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

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