--- Comment #25 from rguenth at gcc dot gnu dot org 2007-03-31 14:42
---
Yes.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-01-14 15:06
---
Can it be the patch changes result of alias analysis? I get (big) runtime
differences (but maybe due to unrelated changes) with the tester from Jan 13
(patched) vs. Jan 14 (unpatched).
--
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02
---
The patch fixed the freefem memory regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
okay, i'll update changelog, submit and commit.
On 13 Jan 2007 23:02:13 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02
---
The patch fixed the freefem memory regression.
--
--- Comment #22 from dberlin at gcc dot gnu dot org 2007-01-14 01:22
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
okay, i'll update changelog, submit and commit.
On 13 Jan 2007 23:02:13 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED]
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-01-11 18:12
---
Again tonight - Mark broke bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-01-10 18:39
---
We'll see with tonights run of the tester. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17
---
Pling!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
Try the attached, let me know how it goes.
On 9 Jan 2007 21:17:05 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17
---
Pling!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
---
--- Comment #17 from dberlin at gcc dot gnu dot org 2007-01-09 21:42
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
Try the attached, let me know how it goes.
On 9 Jan 2007 21:17:05 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #13 from hubicka at gcc dot gnu dot org 2006-12-23 14:26
---
Note that we've got another noticeable jump in memory consumption today (well
at least it would be very important jump if we used just 28MB of memory for
aliasing :). Is that also aliasing or shall be analyzed?
--- Comment #14 from hubicka at gcc dot gnu dot org 2006-12-23 14:27
---
Well, actually the testcase now runs out of memory and ICE...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #15 from dberlin at gcc dot gnu dot org 2006-12-23 16:21
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
On 23 Dec 2006 14:26:00 -, hubicka at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #13 from hubicka at gcc dot
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:32
---
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00959.html fixes the ICE in the
operand scanner.
The alias times should be back to saner values, but the memory consumption
problem is still there. Still looking into
--- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50
---
The memory problem is quite simple: We just have a *lot* of pointers and a
*lot* of addressable symbols. Here is a breakdown of what happens on the first
call to compute_may_aliases:
During the first call to
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 23:54
---
(In reply to comment #9)
The memory problem is quite simple: We just have a *lot* of pointers and a
*lot* of addressable symbols. Here is a breakdown of what happens on the
first
call to
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-12-14 01:11
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
On 13 Dec 2006 23:50:17 -, dnovillo at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #9 from dnovillo at gcc dot
--- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 02:50
---
(In reply to comment #11)
I'll give the bitmaps a try for the operand scanner and see how it works.
OK. Hopefully that won't introduce a huge slowdown in the operand scanner.
Assigning back to you.
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-12-12 16:44 ---
We're now ICEing in
internal compiler error: in ssa_operand_alloc, at tree-ssa-operands.c:365
for the second testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-07 12:40 ---
Numbers with mainline r119612 are
FiniteElementMethod.cpp: 346MB, 46.86s
parse.ff.cc: 1GB, 1236.53s
so actually the latter is the biggest offender here ;) The compiler was built
with release checking (but not
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-12-07 14:07 ---
tree alias analysis :1125.41 (91%) usr 1.57 (31%) sys1127.32 (91%) wall
199468 kB (19%) ggc
PRE : 61.16 ( 5%) usr 0.83 (16%) sys 62.01 ( 5%) wall
2073 kB ( 0%) ggc
TOTAL
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-06 17:17 ---
Created an attachment (id=12758)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12758action=view)
first testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-06 17:18 ---
Created an attachment (id=12759)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12759action=view)
second testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-06 17:20 ---
Before the last big regressions on the mainline the first one took 350MB and
52s to build with -O2 on x86_64, the second one 685MB and 147s. That was g++
(GCC) 4.3.0 20061122 (experimental).
--
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-12-07 04:48 ---
On my machine, with an unoptimized cc1plus (IE stage1), the first one, at -O2
takes 150meg of memory total, and 221 seconds, with most of the time being
verifiers.
This is with local PTA changes to speed up PTA
25 matches
Mail list logo
