similar to: [LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph

On Tue, Aug 9, 2011 at 6:19 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > I am using EQTDDataStructures (from the poolalloc project) to resolve > indirect function calls to over-approximated sets of possible callees. If I remember correctly, it only tries to resolve indirect calls. The analysis doesn't track direct calls because you can do it just as well yourself. Andrew

Andrew Lenharth wrote: > If I remember correctly, it only tries to resolve indirect calls. The > analysis doesn't track direct calls because you can do it just as well > yourself. DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to iterate over an empty set (EmptyActual) for any call site not found in the ActualCallees map. So if direct calls are not tracked,

On Tue, Aug 9, 2011 at 10:45 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > Andrew Lenharth wrote: >> If I remember correctly, it only tries to resolve indirect calls.  The >> analysis doesn't track direct calls because you can do it just as well >> yourself. > > DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to > iterate over an empty

Hi, Ben, As Will suggested, try the TD pass, not EQTD, and see if that works better for you. Having said that, DSA currently doesn't do well with vtables. It is not a fundamental limitation of the algorithm itself and we think we know how to improve it, so if those are important to you, let me know. DSA is indeed a unification-style analysis, not inclusion based. It is partially context

I wrote: > I'll keep poking at this some more and let you folks know if I hit any other surprises. Well, that didn't take long. :-) I have found two new surprises in DSCallGraph as built by TDDataStructures. Consider the following program, which is complete and self-contained and which has one simple indirect call site: volatile int unknown; static void red() { } static void

In an earlier message (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/042298.html), Andrew Lenharth suggested that EQTDDataStructures (from the poolalloc project) may only try to resolve indirect function calls. However, I am now finding that the generated DSCallGraph over-approximates the callees in a very simple indirect call. Some over-approximation is unavoidable, but this case

John Criswell wrote: > 1) I'll try out your example C++ code below and see if I can get the > same results that you do. However, I'm at a conference right now (Usenix > Security), so I don't know exactly when I'll get to it. Excellent. Thanks, John! > 2) DSA can get pessimistic results when dealing with external code (as > Andrew described). It is designed for

Will Dietz wrote: > This is actually the expected behavior for EQTD :). Expected by you, maybe. :-D > If you switch to TD you'll get better alias-analysis information, and > in this example the correct result. OK, I have switched to TDDataStructures as well, and I am also seeing much better (for my purposes) results in simple tests. I'll keep poking at this some more and

On Thu, Aug 11, 2011 at 11:10 AM, Ben Liblit <liblit at cs.wisc.edu> wrote: >        volatile int unknown; > >        static void red() { } >        static void blue() { } > >        int main() >        { >          (unknown ? red : blue)(); >          return 0; >        } > > If I save this as "test.c", compile it with clang, and run my

Dear Ben, Just a few comments on DSA: 1) I'll try out your example C++ code below and see if I can get the same results that you do. However, I'm at a conference right now (Usenix Security), so I don't know exactly when I'll get to it. 2) DSA can get pessimistic results when dealing with external code (as Andrew described). It is designed for whole program analysis, meaning

On Wed, Aug 10, 2011 at 1:39 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > The first of those two calls is a vtable dispatch; the ideal answer would be > Base::virt() const and Derived::virt() const, without red() and blue(). >  Still, vtable lookups are complex, so I could imagine an over-approximation > here. > > The second of those two calls is just a non-deterministic

Any suggestions for how to interpret DSCallGraph's output for the following? I'm trying to use DSCallGraph to get a conservative estimate of a whole-program SCC call graph. I wanted to see how it handles real call-graph cycles involving functions both internal and external to the module. So I made a test program with the following actual call graph, using the standard library's

On Wed, Aug 10, 2011 at 10:37 AM, Ben Liblit <liblit at cs.wisc.edu> wrote: > Equally strange: if I comment out the "base->virt();" call, then DSCallGraph > *does* give the expected answer that "(unknown ? red : blue)()" could call > either red() or blue() but not Base::virt(). Somehow having that > vtable-based call present forces the other call to be

> On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote: >>> [snip] >>> -- John T. >> Sorry, I am asking the second question. >> " >> how to determine, within an LLVM pass, what the >> possible target(s) of an indirect function call might be? > > There are at least two solutions. > > The first is to use the CallGraph analysis pass. It

I would like to use R to perform a logistic regression with about 30,000 independent variables. That's right, thirty thousand. Most will be irrelevant: the intent is to use the regression to identify the few that actually matter. Among other things, this calls for giving glm() a colossal "y ~ ..." formula with thirty thousand summed terms on its right hand side. I build up the

I am trying to add a Samba 2.0.7 box to an existing domain. The Samba box will not be a domain controller; it's just going to be a nondescript member of the domain. The primary domain controller is running Windows 2000, but is also configured to emulate an NT4 PDC. Our system administrators did their side of things, and told me that user "domain\liblit" now has permission to add

Using ssh-keygen from OpenSSH-2.9p1, I can perform the following key conversions: - convert a commercial public key into an OpenSSH public key: % ssh-keygen -i -f commercial-key.pub > openssh-key.pub - convert a commercial private key into an OpenSSH private key, provided that the commercial key has no password % ssh-keygen -i -f commercial-key > openssh-key -

> On 1/26/11 3:00 PM, songlh at cs.wisc.edu wrote: >>> On 1/26/11 2:40 PM, songlh at cs.wisc.edu wrote: >>>> thanks! >>>> >>>> After I check the ll file, I find this: >>>> >>>> %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048 >>>> %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg

Dear Prof. Ripley, you mention the theory of perceptrons. Could you please point me to an introduction paper or book? Thanks in previous, Dominik > -----Original Message----- > From: ripley at stats.ox.ac.uk [mailto:ripley at stats.ox.ac.uk] > Sent: dimanche, 10. novembre 2002 18:55 > To: Ben Liblit > Cc: r-help at stat.math.ethz.ch > Subject: Re: [R] building a formula for

On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote: >> [snip] >> -- John T. > Sorry, I am asking the second question. > " > how to determine, within an LLVM pass, what the > possible target(s) of an indirect function call might be? There are at least two solutions. The first is to use the CallGraph analysis pass. It constructs a conservative call graph, meaning that