[LLVMdev] Status of poolalloc, and in particular DSA

[Zvonimir Rakamaric]

On Fri, Dec 7, 2012 at 5:17 PM, John Criswell <criswell at illinois.edu> wrote:
> On 12/6/12 4:47 PM, Zvonimir Rakamaric wrote:
>>
>> 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.

Sorry I wasn't clear here...
I am perfectly fine that poolalloc tracks LLVM releases. In fact,
that's what I am planning to do with SMACK and just track LLVM
releases and not LLVM trunk. So that should work well for me, and
there is no need to follow LLVM trunk.

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

Awesome!

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

Thanks for the info. Yes, I'll definitely give it a try...

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

That's the main thing I wanted to hear. It somewhat assures me that my
investment into using DSA again won't go down the drain as soon as
LLVM moves ahead a release or two....

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

For sure! I am in academia myself, so I know how things are.
In fact, we are looking to hire a programmer who is familiar with LLVM
to help us with this and other similar efforts (we use LLVM a lot in
our tools). So if you know anybody who fits that profile and is
interested to work on challenging problems in a research environment,
please feel free to pass them my contacts.

Thanks John!

Best,
-- Zvonimir