[LLVMdev] incorrect DSCallGraph for simple indirect call with vtable nearby

[Ben Liblit]

Andrew Lenharth wrote:
> It's hard to say without looking at the bytecode.

Thanks for the speedy reply, Andrew.  I'm happy to provide that bytecode 
if it would help.  Binary form or LLVM assembly source code form?  On 
this list or off-list directly to you?

> That set includes red and blue obviously.  However, since they are
> both externally visible, they may, through base, alias virt.  DSA
> pulls the alias set, not the minimal flow-based set of possible
> callees.

Oh, I see.  I was assuming something inclusion-based, as in Andersen's 
analysis.  But if DSA is fundamentally unification-based (as in 
Steensgaard's analysis), that could explain why red() and blue() and 
Base::virt() all end up lumped together.

If that is true, then I'll definitely need a different approach to 
resolving indirect calls.  The code I intend to analyze is vtable-rich, 
so unification through those vtables is going to infect just about 
everything, making my analysis too conservative to be useful in practice.

Does anyone know of an inclusion-based alternative, either in poolalloc 
or core LLVM or any other openly-available LLVM component?  Surely there 
must be a decent LLVM implementation of an inclusion-based alias 
analysis out there somewhere...?

-- Ben