http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #25 from Steven Bosscher steven at gcc dot gnu.org 2012-11-05
22:02:18 UTC ---
This problem has been fixed in DF with the DF_RD_PRUNE_DEAD_DEFS flag.
I see no good reason to deprecate the param, though. For such a huge
loop,
--- Comment #24 from jakub at gcc dot gnu dot org 2009-02-20 12:56 ---
Subject: Bug 39157
Author: jakub
Date: Fri Feb 20 12:56:01 2009
New Revision: 144320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144320
Log:
PR middle-end/39157
* Makefile.in
--- Comment #21 from jakub at gcc dot gnu dot org 2009-02-13 09:17 ---
To answer 2), I bet fwprop would suffer the same problem, but fwprop is
disabled at -O1, LICM is not. I can try it today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #22 from rguenther at suse dot de 2009-02-13 11:06 ---
Subject: Re: Code that compiles fine in 1GB of memory
with 4.1.2 requires 20GB in 4.2.* and higher
On Thu, 12 Feb 2009, lucier at math dot purdue dot edu wrote:
--- Comment #19 from lucier at math dot purdue
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-02-13 11:08
---
Lemme close this bug as a dup of the one marked as regression.
*** This bug has been marked as a duplicate of 26854 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-12 09:58 ---
Is this the same as PR26854? Note that it would be extremely helpful to have
a testcase that fits into less memory to be able to analyze this. As you say
it is autogenerated source, can you shrink the testcase?
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-12 10:41 ---
The peak on x86_64 (with normal checking cc1) seems to be around 29.3GB, but
most of the time top numbers were in the .5GB - 1GB or at most 1.3GB range,
with just a signle very high peak. Will now look closer where
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-12 10:46 ---
If it is like PR26854 then it is all df memory. The gambit stuff consists of
a state machine with loads of computed gotos (thus a nearly fully connected
CFG) IIRC.
--
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-12 11:26 ---
Even for code with lots of computed gotos, the CFG should not be fully
connected. We factorize computed gotos to avoid exactly that. At least we used
to. Maybe the factorizing is broken, or it is undone somewhere
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-02-12 11:40
---
Even for code with lots of computed gotos, the CFG should not be fully
connected. We factorize computed gotos to avoid exactly that. At least we
used
to. Maybe the factorizing is broken, or it is undone
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-12 12:01 ---
In the past, we did not unfactor them (see e.g. Bug 15242).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2009-02-12 12:16 ---
Adding -fno-move-loop-invariants to the x86_64 mentioned options results in
VIRT memory topping around 1224m (only because of IRA, before RA it never went
above 1GB). Seems it is really the loop2_invariant pass that
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-12 12:49 ---
If there is a test case that compiles in less than 4GB, I'll take this bug (I
have no access to machines with more memory than that ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-12 12:58 ---
PR26854 is fixed as well with -fno-move-loop-invariants. It has a little
less peak memory requirement than the testcase here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #10 from jakub at gcc dot gnu dot org 2009-02-12 13:16 ---
Most of the memory is allocated in df_chain-block_pool:
p *df-problems_by_index[4]-block_pool
$37 = {name = 0xbc3114 df_chain_block pool, id = 475, elts_per_block = 50,
returned_free_list = 0x0,
virgin_free_list =
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-12 14:21 ---
Created an attachment (id=17288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17288action=view)
gcc44-pr39157.patch
Quick hack to avoid loop invariant motion from excessively large loops at -O1.
With this cc1
--- Comment #12 from rguenther at suse dot de 2009-02-12 14:23 ---
Subject: Re: Code that compiles fine in 1GB of memory
with 4.1.2 requires 20GB in 4.2.* and higher
On Thu, 12 Feb 2009, jakub at gcc dot gnu dot org wrote:
--- Comment #11 from jakub at gcc dot gnu dot org
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-02-12 15:47
---
Zdenek, in this case (and PR26854) can we make sure not to recognize loops
that involve the single non-local goto BB? Maybe this would solve the
problem as well.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #14 from jakub at gcc dot gnu dot org 2009-02-12 15:57 ---
Created an attachment (id=17291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17291action=view)
gcc44-pr39157.patch
Patch to add loop-invariant-max-bbs-in-loop parameter.
--
--- Comment #15 from lucier at math dot purdue dot edu 2009-02-12 16:35
---
Some comments (a lot went on while I was sleeping):
1. Yes, this is similar to the test case of PR26854, but the C code generator
has changed significantly since that test case was filed. I don't know if the
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-12 16:52
---
Actually for PR26854 it is just one loop that is detected, covering all of
the function (with approx. 56000 basic blocks and one basic-block that has
edges to all other basic blocks in the loop). So the default
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2009-02-12
18:29 ---
Subject: Re: Code that compiles fine in 1GB of memory with 4.1.2 requires
20GB in 4.2.* and higher
Zdenek, in this case (and PR26854) can we make sure not to recognize loops
that involve the single
--- Comment #18 from lucier at math dot purdue dot edu 2009-02-12 19:54
---
There is now a file slatex.i at
http://www.math.purdue.edu/~lucier/bugzilla/8/
that compiles in about 650MB of memory with gcc-4.2.3 on x86-64 with the same
options; I don't know if that will help Steven.
--- Comment #19 from lucier at math dot purdue dot edu 2009-02-12 20:51
---
Subject: Re: Code that compiles fine in 1GB of
memory with 4.1.2 requires 20GB in 4.2.* and higher
On Thu, 2009-02-12 at 16:52 +, rguenth at gcc dot gnu dot org wrote:
--- Comment #16 from rguenth
--- Comment #20 from steven at gcc dot gnu dot org 2009-02-13 07:44 ---
Re: Moving loop invariants out of this loop might help if it detected as a
loop, but I don't know how to check whether it is. (Comment #19):
It's not like there will not be any loop invariant code motion (LICM) at
25 matches
Mail list logo
