similar to: [LLVMdev] Re: About the 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, In response to Chris's suggestion to construct a more precise callgraph builder. I express my personal thinking here on possible refinement. Any advice is welcome. 1. Basic data structure changes. Current callgraph builder maintains two null nodes, expressing the meaning of "anything calls !internal linkage functions" and "functions not defined in this unit call

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

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

On Fri, 2 Jun 2006, Nai Xia wrote: > The Makefile is sth like this: > > vsftpd: $(OBJS) > gccld -r -native -o vsftpd.o $(OBJS) -L/home/xianai/my_projects/llvm/cfrontend/x86/llvm-gcc/lib/ -lcrtend > gcc -o vsftpd vsftpd.o sysdeputil.o `./vsf_findlibs.sh` > > > But the gcc/ld still cannot find the reference to __main. > Do I have to compile crtend to native to

On Fri, 2 Jun 2006, Nai Xia wrote: > And the command lines: > > llvm-gcc -c -o main.o main.c > gcc -o foo.o foo.c > ar rcs libfoo.a foo.o > llvm-gcc -Wl,-native main.o -L. -lfoo > > It's *OK* > > Thanks in advance for solving my problem. :) > And I personally think it may possiblely puzzle other users, > maybe it deserves its place in FAQ or in man page for

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, 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)

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'

Hi, The "LLVM Language Reference Manual" mentions about "indirect function call". I am just curious about what exactly is the __syntax__ of them and how I can get the callee of an indirect callsite. >From my point of view, there is hardly any cases where indirect calls are needed, because anywhere we use a "fptr" in C, it could just be represented in LLVM IR