Hi Eli, I know the pass that fails, it is MachineCSE. It stack overflows because there are too many recursive calls to processBlock (line 362 of lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am sure there are other places where LLVM makes recursive calls. Or is recursion forbidden in LLVM, and explicitly stated to be so? Cheers, Nicolas On Tue, Apr 13, 2010 at 5:56 PM, Eli Friedman <eli.friedman at gmail.com>wrote:> On Tue, Apr 13, 2010 at 2:29 AM, Konrad Hinsen > <konrad.hinsen at fastmail.net> wrote: > > On 11.04.2010, at 19:14, nicolas geoffray wrote: > > > >> On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen < > konrad.hinsen at fastmail.net> wrote > >>> I am rather surprised that the size of a method should have an impact > on stack usage, but then I haven't looked at all at how VMKit works yet. > That's my next project :-) > >>> > >> It has no impact on VMKit. The impact is on LLVM optimization passes > that do recursive calls. > > > > I see... Could those passes simply be skipped for code blocks that are > too large? Ideally in LLVM, since it's LLVM that imposes the restriction? I > don't know much about LLVM yet, but my first thought would be that a code > handling system should be able to deal with code of any size. It may decide > not to optimize unusual cases, but it certainly shouldn't crash. > > You're right, it shouldn't crash. Can you track down which pass is > crashing and file a > bug? > > -Eli >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100413/0a28b9f6/attachment.html>
On Apr 13, 2010, at 9:33 AM, nicolas geoffray wrote:> I know the pass that fails, it is MachineCSE. It stack overflows because there are too many recursive calls to processBlock (line 362 of lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am sure there are other places where LLVM makes recursive calls. Or is recursion forbidden in LLVM, and explicitly stated to be so?Recursion certainly isn't forbidden in the LLVM codebase, but anything that makes a number of recursive calls that potentially scales linearly with the size of the data set is a crash hazard. This is just how C works — really how any programming language works, given that the call isn't TCO-able without CPS conversion, which really just hides the problem of completely unnecessary linear space usage. John.
On Tue, Apr 13, 2010 at 9:33 AM, nicolas geoffray <nicolas.geoffray at gmail.com> wrote:> Hi Eli, > I know the pass that fails, it is MachineCSE. It stack overflows because > there are too many recursive calls to processBlock (line 362 of > lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am > sure there are other places where LLVM makes recursive calls. Or is > recursion forbidden in LLVM, and explicitly stated to be so?Unbounded recursion is generally considered a bug; please file. -Eli> On Tue, Apr 13, 2010 at 5:56 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: >> >> On Tue, Apr 13, 2010 at 2:29 AM, Konrad Hinsen >> <konrad.hinsen at fastmail.net> wrote: >> > On 11.04.2010, at 19:14, nicolas geoffray wrote: >> > >> >> On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen >> >> <konrad.hinsen at fastmail.net> wrote >> >>> I am rather surprised that the size of a method should have an impact >> >>> on stack usage, but then I haven't looked at all at how VMKit works yet. >> >>> That's my next project :-) >> >>> >> >> It has no impact on VMKit. The impact is on LLVM optimization passes >> >> that do recursive calls. >> > >> > I see... Could those passes simply be skipped for code blocks that are >> > too large? Ideally in LLVM, since it's LLVM that imposes the restriction? I >> > don't know much about LLVM yet, but my first thought would be that a code >> > handling system should be able to deal with code of any size. It may decide >> > not to optimize unusual cases, but it certainly shouldn't crash. >> >> You're right, it shouldn't crash. Can you track down which pass is >> crashing and file a >> bug? >> >> -Eli > >
Filed: http://llvm.org/bugs/show_bug.cgi?id=6876 Cheers, Nicolas On Tue, Apr 13, 2010 at 10:56 PM, Eli Friedman <eli.friedman at gmail.com>wrote:> On Tue, Apr 13, 2010 at 9:33 AM, nicolas geoffray > <nicolas.geoffray at gmail.com> wrote: > > Hi Eli, > > I know the pass that fails, it is MachineCSE. It stack overflows because > > there are too many recursive calls to processBlock (line 362 of > > lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I > am > > sure there are other places where LLVM makes recursive calls. Or is > > recursion forbidden in LLVM, and explicitly stated to be so? > > Unbounded recursion is generally considered a bug; please file. > > -Eli > > > On Tue, Apr 13, 2010 at 5:56 PM, Eli Friedman <eli.friedman at gmail.com> > > wrote: > >> > >> On Tue, Apr 13, 2010 at 2:29 AM, Konrad Hinsen > >> <konrad.hinsen at fastmail.net> wrote: > >> > On 11.04.2010, at 19:14, nicolas geoffray wrote: > >> > > >> >> On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen > >> >> <konrad.hinsen at fastmail.net> wrote > >> >>> I am rather surprised that the size of a method should have an > impact > >> >>> on stack usage, but then I haven't looked at all at how VMKit works > yet. > >> >>> That's my next project :-) > >> >>> > >> >> It has no impact on VMKit. The impact is on LLVM optimization passes > >> >> that do recursive calls. > >> > > >> > I see... Could those passes simply be skipped for code blocks that are > >> > too large? Ideally in LLVM, since it's LLVM that imposes the > restriction? I > >> > don't know much about LLVM yet, but my first thought would be that a > code > >> > handling system should be able to deal with code of any size. It may > decide > >> > not to optimize unusual cases, but it certainly shouldn't crash. > >> > >> You're right, it shouldn't crash. Can you track down which pass is > >> crashing and file a > >> bug? > >> > >> -Eli > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100419/cbe17c17/attachment.html>