2009/4/19 Jan Hubicka <hubi...@ucw.cz>: >> On Sat, Apr 18, 2009 at 7:01 PM, Dave Korn >> <dave.korn.cyg...@googlemail.com> wrote: >> > >> > Hi, >> > >> > I'm getting a stack overflow caused by *very* deep recursion while trying >> > to >> > build gnu/javax/swing/text/html/parser/HTML_401F.o in libjava, >> > bootstrapping >> > HEAD on i686-pc-cygwin. >> > >> > With the default per-thread stack size of 2MB, it crashes in >> > tree_ssa_phiprop_1(), which by the time of the crash has recursed to a >> > depth >> > that I can actually honestly describe as "OVER 9000"! If I boost the >> > stack to >> > 4MB, I find that the recursion does actually bottom out at some point, >> > since >> > the compile completes, but I tested at 3MB and it crashed at a recursion >> > depth >> > of 13924. >> > >> > I know that boostrapping libjava is a tough job and pretty intensive on >> > memory demands, but is this level of nesting actually to be expected, or >> > has >> > something gone astray? >> >> Well, this is one of the usual ways of iterating over the CFG, so this >> is certainly >> not unexpected. Maybe for some reason gsi is not scalarized and stack usage >> of that function is unusually high? > > There used to be rule that we should not expect CFG walk to fit in > stack. I.e. all CFG walking needs to be written with explicit > worklist/stack instead of using recursion. Perhaps it should enforce it > here too? :)
Well ... in this case it's likely the problem that propagate_with_phi is inlined (single-use static function) and maybe other helpers of it too. Maybe we should instead throttle inlining into functions that recurse? ;) Richard. > > Honza >
