[LLVMdev] Status of poolalloc, and in particular DSA

[John Criswell]

On 12/6/12 4:47 PM, Zvonimir Rakamaric wrote:
> Hi all,
>
> I've been using LLVM in my software analysis projects for quite a few
> years now, and several years back I relied on results of DSA analysis
> in my SMACK tool for checking C programs.
>
> At some point that part of SMACK got deprecated, but now I would like
> to revisit it since it was working quite well.
>
> Therefore, I would like to learn what's the status of the poolalloc
> project, and in particular its DSA analysis. I've seen there are
> regular commits, and also there is a branch called release_32, which
> is I presume following LLVM's 3.2 release. If that about right?

Correct.  The release_32 branch of poolalloc works with the release_32 
branch of LLVM (which should be the upcoming LLVM 3.2 to be released soon).

For the moment, we're not planning to have poolalloc trunk track LLVM 
trunk until we're ready to move to the next LLVM version. However, that 
policy decision is up for discussion, so if people need/want poolalloc 
to track trunk, please email the list.

Regarding robustness, DSA should be working well.  I used it when 
compiling the DotGNU C# compiler earlier this year and got it to work.

As far as ability to infer types and disambiguate pointers, I am 
unsure.  I don't know when SMACK started using DSA, but we noticed a few 
years ago that DSA's ability to infer types had diminished. 
Investigation showed that some LLVM optimizations were changing typed 
GEP instructions into byte-level GEP instructions, making type-inference 
more difficult for DSA.  The situation may have changed since then.  My 
recommendation is to try running DSA on a few programs to see if you're 
getting the results you need.

> Basically, I would appreciate if somebody would comment if I can count
> on DSA being supported and following LLVM releases in the future.

DSA is currently maintained by our research group and is a necessary 
component for making SAFECode's run-time checks stronger, so our current 
plans call for continued maintenance of DSA.  However, keep in mind that 
we're an academic research group; we don't have the development 
bandwidth of the entire LLVM community.  If DSA is the best option for 
your project, you may want to consider lending some time to helping us 
maintain it.

-- John T.

> Thanks a lot!
>
> -- Zvonimir
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu          http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev