[llvm-dev] Functions accessible from a function

[Evgeny Astigeevich via llvm-dev]

Hi Alex,

You can find examples of CallGraph uses including CG.getExternalCallingNode() in lib/Transforms/IPO/Inliner.cpp. 

Thanks,
Evgeny Astigeevich

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alex
> Denisov via llvm-dev
> Sent: Wednesday, March 22, 2017 12:53 PM
> To: John Criswell
> Cc: LLVM-Dev; Stanislav Pankevich
> Subject: Re: [llvm-dev] Functions accessible from a function
> 
> > In other words, you're trying to compute the call graph (a graph that shows
> which functions call other functions), correct?
> 
> I called it Call Tree in my head, but yes, this is exactly what I need.
> 
> > LLVM already has a call graph analysis pass
> (http://llvm.org/doxygen/classllvm_1_1CallGraphAnalysis.html) which can
> compute a call graph for you.
> >
> > In your example above, a function escapes to external code.  The call graph
> has an externalCalledNode and an externalCallNode which represents
> functions called by external code and functions calling external code,
> respectively.  You should examine these nodes to understand how external
> code affects the call graph.
> >
> > The call graph analysis within LLVM does not really handle function pointers
> (the results are correct but a very conservative).  If you need to analyze
> function pointers, you might try DSA.
> 
> Thanks a lot, I will look into. If the algorithm doesn’t cover all cases then it is
> still better than my naive approach.
> Could you also tell what’s the DSA is? The most relevant finding I see is the
> “data structure analysis”.
> 
> > On 21 Mar 2017, at 22:05, John Criswell <jtcriswel at gmail.com> wrote:
> >
> > On 3/21/17 1:21 AM, Alex Denisov via llvm-dev wrote:
> >> Hello everybody,
> >>
> >> I am trying to do some static analysis, e.g. find which other functions
> accessible from a function.
> >
> > In other words, you're trying to compute the call graph (a graph that shows
> which functions call other functions), correct?
> >
> >
> >> Current naive implementation goes over each instruction and whether it
> is a call site or not.
> >> It works great so far, but there are some cases where it doesn’t work. For
> example:
> >>
> >>   declare no_source(function: f) // uses f internally
> >>   define foo() { ... }
> >>   define bar() { ... }
> >>
> >>   define buzz() {
> >>     call foo()
> >>     call no_source(&bar)
> >>     ret
> >>   }
> >>
> >> In this case, my implementation catches 'foo' but not 'bar.'
> >> There are must be less trivial but also detectable cases.
> >>
> >> Can anybody give a hint or advice on how to do such kind of analysis?
> >
> > LLVM already has a call graph analysis pass
> (http://llvm.org/doxygen/classllvm_1_1CallGraphAnalysis.html) which can
> compute a call graph for you.
> >
> > In your example above, a function escapes to external code.  The call graph
> has an externalCalledNode and an externalCallNode which represents
> functions called by external code and functions calling external code,
> respectively.  You should examine these nodes to understand how external
> code affects the call graph.
> >
> > The call graph analysis within LLVM does not really handle function pointers
> (the results are correct but a very conservative).  If you need to analyze
> function pointers, you might try DSA.
> >
> > Regards,
> >
> > John Criswell
> >
> >>
> >> Cheers,
> >> Alex.
> >
> >
> > --
> > John Criswell
> > Assistant Professor
> > Department of Computer Science, University of Rochester
> > http://www.cs.rochester.edu/u/criswell
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev