[LLVMdev] DSA Analysis

[John Criswell]

Kevin Streit wrote:
> Hi,
>
> I'm still using the release_26 version of Poolalloc/DSA with llvm 2.6 for my analyses and am currently trying to switch to llvm 2.7 for several reasons. I tried to use the trunk of the poolalloc svn repository with the llvm 2.7 release which is working fine for most of the programs I ran it on so far but for sqlite it's running into a stack overflow since it is endlessly looping in the BUDataStructure::calculateGraphs method (excerpt of the debugging output is attached).
>   

This is a known bug (PR#7929 at 
http://llvm.org/bugs/show_bug.cgi?id=7929). You can work around this 
problem by using the -dsa-no-filter-callcc=true, 
-dsa-no-filter-vararg=true, and -dsa-no-filter-intfp=true options.  
Apparently Will has already fixed it, so the work-around isn't necessary.

That said, there is a bug (we believe it is in BU) that causes memory 
explosion on some programs (like 176.gcc).  You may run into that bug 
once you set the above command line options.  We're still working on 
diagnosing and fixing that bug.

> Since it is actively worked on I'm not asking for a quick solution. I just wanted to send this for case this behavior is not expected and to ask if there is a revision for which the BU DSA is known to work at least stable in most cases such that I can work with llvm 2.7. Or is there any plan on when a stable version for 2.7 (or even better 2.8) will be available?
>   

In general, we try to keep mainline DSA working (i.e., no regressions).  
I don't foresee us introducing any major regressions or instability, but 
it is possible that we may do some refactoring in the near future (next 
6 months) that may introduce regressions.  Using mainline DSA and LLVM 
2.7 will probably be fine, but if you want zero regressions, then I 
recommend using the release_26 branch of DSA as we are no longer 
enhancing it.

As for when there will be a stable DSA for LLVM 2.7, there is no 
concrete plan per se.  The current plan is to keep fixing bugs and keep 
trying it on more programs.  The best answer I can give is that it will 
be done when it is finished.
:)

An update to the LLVM 2.8 API is not planned yet because we're focusing 
on making DSA and Poolalloc more robust.  Updating to LLVM 2.8 isn't 
necessary (yet) and would just complicate the bug finding/fixing process.



> Anyway, thanks for your great work on llvm and dsa.
>   

Thanks.  We're hoping that this effort to get DSA/Poolalloc robust will 
be a benefit to both our research and, some day, for the community at large.

-- John T.

> Cheers, Kevin
>
> --------------------------------------------------------------
> Excerpt of the debugging output:
>
> Visiting single node SCC #: 355 fn: subjournalPage
>   [BU] Calculating graph for: subjournalPage
>     Inlining graph for mallocWithAlarm[14+5] into 'subjournalPage' [18+5]
>     Inlining graph for memjrnlWrite[11+5] into 'subjournalPage' [20+8]
> WARNING: Useless call site found.
> WARNING: Useless call site found.
> WARNING: Useless call site found.
> Deleteing 0x1036e1318
> Merged 4 call nodes.
>   [BU] Done inlining: subjournalPage [18+8]
> Recalculating subjournalPage due to new knowledge
>
> Visiting single node SCC #: 356 fn: subjournalPage
>   [BU] Calculating graph for: subjournalPage
>     Inlining graph for mallocWithAlarm[14+5] into 'subjournalPage' [18+5]
>     Inlining graph for memjrnlWrite[11+5] into 'subjournalPage' [20+8]
> WARNING: Useless call site found.
> WARNING: Useless call site found.
> WARNING: Useless call site found.
> Deleteing 0x1036e1318
> Merged 4 call nodes.
>   [BU] Done inlining: subjournalPage [18+8]
> Recalculating subjournalPage due to new knowledge
>
> .. and this repeats endlessly until my memory runs out ...