Status of poolalloc, and in particular DSA

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?

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

Thanks a lot!

-- Zvonimir

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.

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