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
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.
