After running through bugpoint, I get this reduced function You can reproduce the problem with: opt bugpoint-reduced-function.bc -break-crit-edges -adce -verify Bugpoint is currently trying to narrow down which block breaks this, but is so far failing. It seems to be running out of memory rather than failing on a particular block. This is on freebsd 5.4, X86, llvm is compiled with gcc 3.4.2 -------------- next part -------------- A non-text attachment was scrubbed... Name: bugpoint-reduced-function.bc Type: application/octet-stream Size: 217727 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20051224/b535d637/attachment.obj> -------------- next part -------------- -- -Alex
This was indeed a memory issue - the hard datasize limit on my freebsd box was 512 mb and this opt went over. Increasing hard limit fixed the problem. However, most unices have a 512mb limit - maybe insanely huge functions as this one should be automagically split somewhere? On Dec 24, Alexander Friedman wrote:> > After running through bugpoint, I get this reduced function > > You can reproduce the problem with: > > opt bugpoint-reduced-function.bc -break-crit-edges -adce -verify > > Bugpoint is currently trying to narrow down which block breaks this, > but is so far failing. It seems to be running out of memory rather > than failing on a particular block. > > This is on freebsd 5.4, X86, llvm is compiled with gcc 3.4.2-- -Alex
On Sat, 24 Dec 2005, Alexander Friedman wrote:> This was indeed a memory issue - the hard datasize limit on my freebsd > box was 512 mb and this opt went over. Increasing hard limit fixed > the problem. > > However, most unices have a 512mb limit - maybe insanely huge > functions as this one should be automagically split somewhere?This is clearly a bug. Can you please run the testcase like this: opt test.bc -time-passes -track-memory -disable-output ? When I run this, it looks like domset and post-dom set take about 21M each. Does it take significantly more memory for you? In any case, this is a bug and should be improved. I will look into it when I get a chance in a couple of weeks. That said, please file a bugzilla bug for this to ensure I don't lose track of the issue. Thanks! -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Sat, 24 Dec 2005, Alexander Friedman wrote:> This was indeed a memory issue - the hard datasize limit on my freebsd > box was 512 mb and this opt went over. Increasing hard limit fixed > the problem. > > However, most unices have a 512mb limit - maybe insanely huge > functions as this one should be automagically split somewhere?We've tracked this down to being an apparent problem with the FreeBSD malloc implementation. The test takes 20-40M of memory on linux for various people, but 10-100x that on two different FreeBSD boxes. Linking with Doug Lea's malloc on FreeBSD apparently fixes the problem. Has anyone in llvmdev land run into a problem with the FreeBSD malloc implementation before? Are there any good solutions other than linking to a different malloc implementation? Thanks, -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Sat, 24 Dec 2005, Alexander Friedman wrote:> After running through bugpoint, I get this reduced function > > You can reproduce the problem with: > > opt bugpoint-reduced-function.bc -break-crit-edges -adce -verify > > Bugpoint is currently trying to narrow down which block breaks this, > but is so far failing. It seems to be running out of memory rather > than failing on a particular block. > > This is on freebsd 5.4, X86, llvm is compiled with gcc 3.4.2BTW, Nate recently commited a fix for this issue: http://llvm.org/bugs/show_bug.cgi?id=681 Nate wrote: "Implemented postdom based on Lengauer and Tarjan implementation in forward dom. Speeds up this testcase from 32.8 to 0.8 seconds on my G5, drops memory requirement from 496MB to 26MB." -Chris -- http://nondot.org/sabre/ http://llvm.org/