--- Comment #103 from rguenther at suse dot de 2009-02-21 18:42 ---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Sat, 21 Feb 2009, lucier at math dot purdue dot edu wrote:
--- Comment #102 from lucier at math dot purdue dot edu 2009-02-21
--- Comment #104 from lucier at math dot purdue dot edu 2009-02-21 18:56
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Cool, that leaves me with
DFS = ???
SCC = ? Confict ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #105 from steven at gcc dot gnu dot org 2009-02-21 19:04
---
SCC as in SCCVN
DFS = Depth First Search
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #106 from dberlin at gcc dot gnu dot org 2009-02-21 22:34
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Right.
Basically, the value numbering PRE uses as a pre-pass is known as SCCVN.
It value numbers by doing a depth first
--- Comment #97 from jakub at gcc dot gnu dot org 2009-02-20 13:03 ---
http://gcc.gnu.org/viewcvs?root=gccview=revrev=144320
limits now RTL LICM to loops with less than 1 bbs (-O{2,3,s}) resp. 1000
bbs (-O1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #98 from lucier at math dot purdue dot edu 2009-02-20 19:52
---
Thank you, that indeed fixes the LICM problem.
Based on some comments for this PR and for PR 39157 I thought that a similar
patch might apply to PRE. So with
euler-14% /pkgs/gcc-mainline/bin/gcc -v
Using
--- Comment #99 from lucier at math dot purdue dot edu 2009-02-20 19:54
---
Created an attachment (id=17336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17336action=view)
Memory and CPU statistics when compiling _num.i with -O2
--
--- Comment #100 from lucier at math dot purdue dot edu 2009-02-20 19:56
---
The large memory requirements for LICM at -O1 and -O2 is still a regression for
the 4.2 and 4.3 branches. Jakub's patch is short and elegant; do you think it
would be a good idea to backport it to the other
--- Comment #101 from dberlin at gcc dot gnu dot org 2009-02-21 04:13
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
PRE already gives up on this testcase, at least on my computer, and
takes no memory.
All of the memory here is being eaten
--- Comment #95 from stevenb dot gcc at gmail dot com 2009-02-15 11:26
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Re: Comment #94
The trouble with LCM in RTL (i.e. GCSE-PRE) is not that it is slow (or
that it is disabled -- istr it is
--- Comment #96 from dberlin at gcc dot gnu dot org 2009-02-16 02:07
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Uh, it's most certainly disabled on testcases like his.
look at is_too_expensive in gcse.c
This is in fact done because LCM
--- Comment #92 from stevenb dot gcc at gmail dot com 2009-02-14 14:42
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Re: Comment #88
I think the patch is perfectly acceptable as a stop-gap solution. I
don't think we have anything better
--- Comment #93 from lucier at math dot purdue dot edu 2009-02-14 21:58
---
Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines
I instrumented the compiler and looked how many nodes were in each
loop processed by LICM for the Gambit runtime and compiler.
--- Comment #94 from dberlin at gcc dot gnu dot org 2009-02-14 23:06
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
One of the reasons LCM in RTL is so slow is because it uses a crappy
iteration order.
With the right iteration order, it
--- Comment #85 from rguenth at gcc dot gnu dot org 2009-02-13 11:08
---
*** Bug 39157 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #86 from lucier at math dot purdue dot edu 2009-02-13 15:40
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
It's unfortunate that the discussion from 39157 will be somewhat hard to
find now that that bug is closed.
Steven wrote in a
--- Comment #90 from lucier at math dot purdue dot edu 2009-02-13 17:37
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote:
--- Comment #87 from bonzini at gnu dot org 2009-02-13
--- Comment #91 from lucier at math dot purdue dot edu 2009-02-13 17:43
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 17:37 +, lucier at math dot purdue dot edu
wrote:
--- Comment #90 from lucier at math dot purdue
--- Comment #80 from bonzini at gnu dot org 2009-02-04 12:45 ---
Brad, can you produce new stats?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #81 from lucier at math dot purdue dot edu 2009-02-04 17:27
---
Created an attachment (id=17243)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17243action=view)
Memory and CPU statistics for 2009/02/04
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #82 from lucier at math dot purdue dot edu 2009-02-04 17:28
---
I still have the bitmap.c patch from
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html
in my tree so I don't get meaningless statistics for bitmaps. (Kenny installed
in the trunk something like the
--- Comment #83 from dberlin at gcc dot gnu dot org 2009-02-04 18:24
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
These numbers claim a leak of the graph-preds bitmap (and related
bitmaps) which are quite clearly freed all the time.
These
--- Comment #79 from rguenth at gcc dot gnu dot org 2009-01-24 10:19
---
GCC 4.3.3 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #76 from lucier at math dot purdue dot edu 2008-09-26 15:43
---
Created an attachment (id=16411)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16411action=view)
memory and cpu time statistics for 2008-09-19
There has been a 13% compile-time regression on this PR since
--- Comment #77 from lucier at math dot purdue dot edu 2008-09-26 15:44
---
Created an attachment (id=16412)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16412action=view)
memory and cpu statistics for 9/25
Here is a timing report from today.
--
--- Comment #78 from lucier at math dot purdue dot edu 2008-09-26 15:45
---
Created an attachment (id=16413)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16413action=view)
Memory and cpu statistics from 9/16
Sorry, I included the wrong file; this should be the correct one from
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.3.3
--- Comment #75 from lucier at math dot purdue dot edu 2008-09-18 01:19
---
Created an attachment (id=16350)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16350action=view)
statistics with checking enabled and using longs to count bytes
Using the patch from
28 matches
Mail list logo
