> On Mon, Apr 20, 2009 at 8:29 AM, Paolo Bonzini <bonz...@gnu.org> wrote:
> > Dave Korn wrote:
> >> Richard Guenther wrote:
> >>
> >>> 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.
> >>
> >> It is inlined. I rebuilt jc1 after adding __attribute__ ((noinline)),
> >> and
> >> the stack frame size for tree_ssa_phiprop_1 went down from 0xcc to 0x3c, so
> >> that buys us some breathing room, but the problem is still lurking there;
> >> compilation of a larger function could still trip it. (It saved enough
> >> headroom for my trial build of the libjava html parser to complete
> >> successfully.)
> >>
> >> Should we be concerned that end-users might run into this in real-world
> >> situations when they're compiling large files of bulk auto-generated code?
> >
> > Indeed we should use dom-walk.c, or better copy the worklist approach
> > from it.
> >
> > worklist[sp++] = ENTRY_BLOCK_PTR;
> > while (sp)
> > {
> > bb = worklist[--sp];
> > for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> > did_something |= propagate_with_phi (bb, gsi_stmt (gsi), phivn, n);
> >
> > for (dest = first_dom_son (walk_data->dom_direction, bb);
> > dest; dest = next_dom_son (walk_data->dom_direction, dest))
> > worklist[sp++] = dest;
> > }
> > return did_something;
>
> Feel free to post patches replacing the various similar walks with
> the above pattern (or add a FOR_EACH_BB_IN_DOM_ORDER
I am very sure I implemented dom order iterators and FOR_EACH* macro
once for this reason. Will try to search archives.
Honza
> that does it, possibly with a BREAK_FROM_.... that frees the
> VEC used for the worklist).
>
> grep next_dom_son *.c
>
> only finds 22 possible uses of the above pattern.
>
> dom-walk.c is indeed overkill for the simple cases.
>
> Thanks,
> Richard.
