--- Comment #36 from jaydub66 at gmail dot com 2008-01-09 09:38 ---
How does the trunk compare now to the numbers mentioned in comment #16 ?
Compiling with rev. 131414 gives:
-O1 -fstrict-aliasing: 33sec, 438197 kB
-O2: 97sec, 669637 kB
-O3:
--- Comment #37 from rguenther at suse dot de 2008-01-09 09:45 ---
Subject: Re: [4.3 Regression] Fortran FE
generated IL pessimizes middle-end IL and analysis
On Wed, 9 Jan 2008, jaydub66 at gmail dot com wrote:
--- Comment #36 from jaydub66 at gmail dot com 2008-01-09 09:38
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-08 09:55
---
The unroll problem is that if you have multiple loops like
for (i=0; i3; ++i)
a[i] = i;
...
for (i=0; i3; ++i)
a[i] = i;
then even though we are in loop closed SSA form, we rename all
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-01-08 09:46
---
The patch in comment #14 reduces compile time from 120s to 80s. I'll try to
get it into shape.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #26 from rguenth at gcc dot gnu dot org 2008-01-08 11:06
---
We do a _lot_ of calls to var_ann during the compilation:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call
--- Comment #27 from rguenth at gcc dot gnu dot org 2008-01-08 12:13
---
Subject: Bug 34683
Author: rguenth
Date: Tue Jan 8 12:12:56 2008
New Revision: 131393
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131393
Log:
2008-01-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #29 from steven at gcc dot gnu dot org 2008-01-08 12:18 ---
Re. comment #26
More proof that assert checking _is_ expensive. I wonder how much compile time
can be blamed overall on release checking (i.e. checking disabled vs. release
checking).
Have you ever compared e.g.
--- Comment #28 from steven at gcc dot gnu dot org 2008-01-08 12:17 ---
Re. comment #26
More proof that assert checking _is_ expensive. I wonder how much compile time
can be blamed overall on release checking (i.e. checking disabled vs. release
checking).
Have you ever compared e.g.
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-01-08 12:30
---
No, I didn't. But yes, overzealous asserts in the simple inline accessor
functions are probably counter-productive. For example things like
static inline bool
gimple_aliases_computed_p (const struct function
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-08 12:55
---
Another hot assert is
static inline tree
memory_partition (tree sym)
{
tree tag;
/* MPTs belong to their own partition. */
if (TREE_CODE (sym) == MEMORY_PARTITION_TAG)
return sym;
gcc_assert
--- Comment #32 from steven at gcc dot gnu dot org 2008-01-08 13:08 ---
You are of course right that for this test case the bigger win is in the
algorithmic issues.
On the other hand, for compile time in general, the gcc_asserts are IMHO the
worst thing that happened to GCC since the
--- Comment #33 from rguenth at gcc dot gnu dot org 2008-01-08 16:29
---
Subject: Bug 34683
Author: rguenth
Date: Tue Jan 8 16:29:14 2008
New Revision: 131400
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131400
Log:
2008-01-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #34 from rguenth at gcc dot gnu dot org 2008-01-08 21:22
---
Subject: Bug 34683
Author: rguenth
Date: Tue Jan 8 21:21:29 2008
New Revision: 131404
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131404
Log:
2008-01-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #35 from steven at gcc dot gnu dot org 2008-01-09 00:04 ---
How does the trunk compare now to the numbers mentioned in comment #16 ?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-07 13:25
---
Most of the operand scanner time is caused by cfg_cleanup:
tree CFG cleanup : 93.71 (79%) usr 1.16 (54%) sys 95.03 (78%) wall
474427 kB (28%) ggc
globbing CFG cleanup (and operand scanner) time to the
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-07 14:32
---
-fno-tree-loop-optimize reduces compile-time of this testcase from 117s to 35s
with -O -fstrict-aliasing. try_unroll_loop_completely calls update_ssa, for
every loop unrolled, added by r98599, which seems to be
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-07 14:50
---
Subject: Bug 34683
Author: rguenth
Date: Mon Jan 7 14:49:36 2008
New Revision: 131375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131375
Log:
2008-01-07 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-01-07 15:08
---
Without the loop optimizer the profile looks like:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-01-07 15:56
---
A histogram over the number of VUSEs/VDEFs that are being sorted by sort_vuses
reveals:
180 2
281964 256
1498 4
that is, we call qsort 281964 times with 256 virtual operands in the VEC. Now,
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-07 17:08
---
Zdenek, can you have a look if there is sth low-hanging with the tree level
loop unroller?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
20 matches
Mail list logo
