------- Comment #8 from rguenth at gcc dot gnu dot org 2008-02-15 13:32 -------
We can, similarly to limiting the overall SCC size, limit the depth to where
we search. This testcase hits the stack limit on x86_64 with an unoptimized
cc1 built with gcc 4.2 with
(gdb) print *sccstack
$2 = {base = {num = 25069, alloc = 35065, vec = {0x2b201c6f8c60}}}
as we limit the SCC size to 10000 we might as well limit the SCC stack size
to some magic number.
Or gcc could simply upper the (soft) stack limit with setrlimit...
Note that DFS in a bootstrapped compiler with release checking enabled doesn't
use an excessive amount of stack, but only pushes 6 registers (which are of
course 64bit wide) and allocates room for 56 extra bytes, which makes the
stack space used per recursion 110 bytes.
All big structures (in particular the ssa_op_iter) are scalarized though,
at least if VN_INFO is not inlined (if marked with always_inline ssa_op_iter
is not scalarized because then op_iter_next_use is not inlined). So we
may run into some inlining issues here (all of op_iter_* in tree-flow-inline.h
_are_ big, so they definitely get defered to the final inlining phase while
VN_INFO is (w/o checking) inlined by the early inliner). But at least
I don't see traces of op_iter_* calls in a bootstrapped compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
