--- Comment #22 from rguenth at gcc dot gnu dot org 2008-02-17 16:24
---
The patch was successfully bootstrapped and tested on x86_64-unknown-linux-gnu
and doesn't show overall negative effects on compile-time or memory-usage on
our daily testers. I am considering it for 4.3.1 after
--- Comment #12 from marcus at jet dot franken dot de 2008-02-16 08:45
---
i configure gcc with just --enable-languages=cso whatever is currently the
default.
btw, today it builds without too deep recursion again :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
--- Comment #13 from steven at gcc dot gnu dot org 2008-02-16 09:33 ---
Re. comment #8
You can't terminate the DFS before a complete SCC is found, it will break the
correctness of the SCC-VN algorithm. You'd start another DFS from a
not-yet-marked SSA name that is in the SCC's DFS
--- Comment #14 from steven at gcc dot gnu dot org 2008-02-16 09:40 ---
For those who have no idea what we're talking about, check out these links.
The first link is Tarjan's algorithm, which is what the tree-ssa-sccvn.c
SCC-finder is based on. The second link is Pearce's improved
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-02-16 10:41
---
re comment #13 - limiting the DFS walk depth will of course only work if we
then abort SCCVN completely (like we do for the SCC size limit). But still
finding a magic number that fixes only the case where we blow
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-02-16 11:23
---
The problem with doing a non-recursive version of DFS as for GCC SCCVN is to
split the FOR_EACH_PHI_OR_STMT_USE walk. You would need to open-code this
and keep a stack of ssa_op_iters, ugly but certainly not
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-02-16 12:11
---
Created an attachment (id=15167)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15167action=view)
patch that still needs some love
Something like this?
--
rguenth at gcc dot gnu dot org changed:
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-02-16 12:49
---
Created an attachment (id=15168)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15168action=view)
patch
Patch which got some minimal testing and love.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-02-16 12:51
---
Note that while it definitely improves stack usage, the total memory usage is
likely to go up (vectors allocate some extra heap, the iters are now
addressable
and thus consume full memory) and as the ssa_op_iter
--- Comment #20 from dberlin at gcc dot gnu dot org 2008-02-16 14:56
---
Subject: Re: [4.3 Regression] crash by too deep recursion in DFS
tree-ssa-sccvn.c:1898
So, there are better SCC algorithms.
In particular, Nuutilla's algorithm will avoid placing a bunch of
nodes on the stack
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-02-16 15:22
---
The patch only avoids using the stack in favor of maintaining heap allocated
stacks. The algorithm is still recursively walking the graph.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
--- Comment #7 from rguenther at suse dot de 2008-02-15 09:08 ---
Subject: Re: [4.3 Regression] crash by too deep
recursion in DFS tree-ssa-sccvn.c:1898
On Thu, 14 Feb 2008, steven at gcc dot gnu dot org wrote:
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-14 23:25
--- 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
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-15 13:35 ---
Shouldn't we make sure, eventually by an ALWAYS_INLINE macro, that all of our
iterator functions are inlined so they definitely can be scalarized?
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-02-15 16:29
---
Well always is to be taken with a grain of salt. The testcase doesn't look
common, but is a huge machine-generated piece of cr*p :P
Otherwise this always also applies to wrong-code and rejects-valid bugs.
If
--- Comment #10 from steven at gcc dot gnu dot org 2008-02-15 16:20 ---
Re. comment #7, sure this can be P1 and block the release. SCC-VN doesn't have
to be fixed for the release. This bug can be worked around.
Not making a bug P1 because you want a release out the door is not a good
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-14 23:25 ---
Should be P1.
This bug is shows an intrinsic scalability problem with SCC-VN as it is
implemented right now (and presented in the literature).
The key issue is, SCC-VN should use a non-recursive SCC finding
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
|
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-14 23:22 ---
x86_64-linux has a default stack limit of 8MB.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
19 matches
Mail list logo
