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). 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? Anyway, thanks for your great work on llvm and dsa. 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 ... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4832 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100824/0f8733e5/attachment.bin>
On Tue, Aug 24, 2010 at 2:12 AM, Kevin Streit <kevin.streit at googlemail.com> 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). >Yep, I'm familiar with the error. Does this still happen after the commits from last night?> 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? >Thanks for understanding that it's a work-in-progress, and appreciate the report. I don't believe there's a stable revision for 2.7, that's what we're working for presently :). If you'd like, feel free to send me the bitcode file and I can try to prioritize fixing the issue you're seeing if it's not fixed already. Alternatively consider filing a bugreport, both DSA and poolalloc have projects on the bug tracker (http://llvm.org/bugs), so we can take care of it... and again an example demonstrating your issue is appreciated if possible. Hope this helps, ~Will Dietz
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 ...
Hi, On Aug 24, 2010, at 6:15 PM, John Criswell wrote:> 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.Oh, sorry. Didn't find that bug. Will Dietz asked me to send him my Bitcode file since the problem is still there in the current revision (111918).>> 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.DSA is already a great benefit for us and I'm sure that making it more robust will be too. Cheers, Kevin Streit -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100824/ba343588/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4832 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100824/ba343588/attachment.bin>
On Tue, Aug 24, 2010 at 11:15 AM, John Criswell <criswell at illinois.edu> wrote:> 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.Fixed with respect to the bug description and the provided test case, and I believe in all such bugs due to filtering. Note that even with these options (disabling filtering) his test case still fails--it would appear that while this has the same symptom (calculateGraphs infinitely recursing) it's not because of the same thing (filtering callees). So this might deserve its own bug report, shrug, not sure best policy here. Either way we should fix it :). ~Will