public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
@ 2005-01-14 14:31 ` steven at gcc dot gnu dot org
2005-01-15 6:11 ` pinskia at gcc dot gnu dot org
` (10 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-14 14:31 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Last reconfirmed|2004-10-08 18:44:35 |2005-01-14 14:30:56
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
2005-01-14 14:31 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks steven at gcc dot gnu dot org
@ 2005-01-15 6:11 ` pinskia at gcc dot gnu dot org
2005-01-15 7:31 ` echristo at redhat dot com
` (9 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-15 6:11 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-15 06:11 -------
Is there an even way to fix this to even produce correct code?
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
2005-01-14 14:31 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks steven at gcc dot gnu dot org
2005-01-15 6:11 ` pinskia at gcc dot gnu dot org
@ 2005-01-15 7:31 ` echristo at redhat dot com
2005-01-15 12:25 ` steven at gcc dot gnu dot org
` (8 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: echristo at redhat dot com @ 2005-01-15 7:31 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From echristo at redhat dot com 2005-01-15 07:31 -------
Thought I did last time.. otherwise I'm not sure what the question is.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (2 preceding siblings ...)
2005-01-15 7:31 ` echristo at redhat dot com
@ 2005-01-15 12:25 ` steven at gcc dot gnu dot org
2005-01-15 16:23 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-15 12:25 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-01-15 12:25 -------
You'd almost think Andrew is not a native speaker.
What I think he asks is: "Can the patch that caused this be done in a different
way such that the code is still correct but the compile time regression goes away."
--
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Last reconfirmed|2005-01-14 14:30:56 |2005-01-15 12:25:26
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (3 preceding siblings ...)
2005-01-15 12:25 ` steven at gcc dot gnu dot org
@ 2005-01-15 16:23 ` pinskia at gcc dot gnu dot org
2005-01-28 18:50 ` ian at airs dot com
` (6 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-15 16:23 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-15 16:23 -------
(In reply to comment #25)
(Well considering, I asked the same question which Eric was asking, or really I was asking the same
question).
And Eric put this into waiting for a reason and I am keeping it there.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (4 preceding siblings ...)
2005-01-15 16:23 ` pinskia at gcc dot gnu dot org
@ 2005-01-28 18:50 ` ian at airs dot com
2005-05-19 17:26 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0/4.1 " mmitchel at gcc dot gnu dot org
` (5 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: ian at airs dot com @ 2005-01-28 18:50 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ian at airs dot com 2005-01-28 18:49 -------
We aren't waiting for anything, so move out of WAITING state.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |ian at airs dot com
Status|WAITING |NEW
Last reconfirmed|2005-01-15 12:25:26 |2005-01-28 18:49:55
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0/4.1 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (5 preceding siblings ...)
2005-01-28 18:50 ` ian at airs dot com
@ 2005-05-19 17:26 ` mmitchel at gcc dot gnu dot org
2005-07-22 21:15 ` [Bug rtl-optimization/13931] [3.4/4.0/4.1 " pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2005-05-19 17:26 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.4.4 |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (6 preceding siblings ...)
2005-05-19 17:26 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0/4.1 " mmitchel at gcc dot gnu dot org
@ 2005-07-22 21:15 ` pinskia at gcc dot gnu dot org
2005-07-25 3:09 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-07-22 21:15 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 21:13 -------
Moving to 4.0.2 pre Mark.
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.4.5 |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (7 preceding siblings ...)
2005-07-22 21:15 ` [Bug rtl-optimization/13931] [3.4/4.0/4.1 " pinskia at gcc dot gnu dot org
@ 2005-07-25 3:09 ` pinskia at gcc dot gnu dot org
2005-09-27 5:11 ` ian at airs dot com
` (2 subsequent siblings)
11 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-07-25 3:09 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 02:59 -------
I think this has been fixed on the mainline:
600 .7s
1200 1.899s
1800 3.7s
2400 5.945s
This is all with checking still enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (8 preceding siblings ...)
2005-07-25 3:09 ` pinskia at gcc dot gnu dot org
@ 2005-09-27 5:11 ` ian at airs dot com
2005-09-27 5:33 ` ian at airs dot com
2005-09-27 16:10 ` mmitchel at gcc dot gnu dot org
11 siblings, 0 replies; 22+ messages in thread
From: ian at airs dot com @ 2005-09-27 5:11 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ian at airs dot com 2005-09-27 05:10 -------
The code in combine is no better than it ever was. What has changed is this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html
which causes the optimization of incrementing a memory location to be done at
expand time rather than at combine time. Thus in 4.1 this particular test case
is no longer slow. I will attach a new test case.
I can see some straightforward potential fixes. Instead of doing the loop to
look for a place to put the REG_DEAD note, just set the bit in refresh_blocks to
rerun life analysis. Or if keeping the loop seems useful (after all, the loop
is itself an attempt to control compilation time), at least limit it to looking
back just a few instructions, to avoid the quadratic behaviour.
A more complex way to fix it would be keep track of which registers are
completely set by i1 and i2. If we find a REG_DEAD note for a register which is
set by i1 or i2, and that register no longer appears in the new i2 and i3, then
we don't care about that REG_DEAD note.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (9 preceding siblings ...)
2005-09-27 5:11 ` ian at airs dot com
@ 2005-09-27 5:33 ` ian at airs dot com
2005-09-27 16:10 ` mmitchel at gcc dot gnu dot org
11 siblings, 0 replies; 22+ messages in thread
From: ian at airs dot com @ 2005-09-27 5:33 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ian at airs dot com 2005-09-27 05:33 -------
Eric, your patch which caused the quadratic behaviour is here:
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01358.html
I know this is a real long-shot, but do you have any recollection of what
problem you were solving? That is, which test case was failing before you
checked in your patch? And how was it failing? The failure case looks
relatively benign to me--we think that a register lives longer than it really does.
To me that old code looks pretty much right--in fact it is one of the
suggestions I made in my previous comment. In comment #20 you say there was a
comment in the code which indicated that it didn't always do the right thing,
and in fact you removed that comment in your patch:
- - there are extremely rare cases (see distribute_regnotes) when a
- REG_DEAD note is lost
But in fact that comment not only was correct but still is correct. In some
cases, a REG_DEAD note will be lost, and in those cases the code sets a bit in
refresh_blocks and reruns life analysis.
Actually, I can see that there is a bug in the original code in some unusual
cases. It relies on reg_set_p to see whether the register is set and therefore
the REG_DEAD note can be discarded. But really we can only casually remove the
REG_DEAD note if the register is completely set, and reg_set_p can return true
if the register is partially set. For example, if a STRICT_LOW_PART is used
when setting the register, we may wind up losing the REG_DEAD note incorrectly.
I think that we can only ignore the register if dead_or_set_p returns true for it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
` (10 preceding siblings ...)
2005-09-27 5:33 ` ian at airs dot com
@ 2005-09-27 16:10 ` mmitchel at gcc dot gnu dot org
11 siblings, 0 replies; 22+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2005-09-27 16:10 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.0.2 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/13931] New: combiner much slower on big functions
@ 2004-01-30 12:41 bonzini at gnu dot org
2004-10-30 20:02 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks mmitchel at gcc dot gnu dot org
` (9 more replies)
0 siblings, 10 replies; 22+ messages in thread
From: bonzini at gnu dot org @ 2004-01-30 12:41 UTC (permalink / raw)
To: gcc-bugs
The combiner jumped up from 3.3.2's 8% to 3.4/3.5's 56% in the attached function.
No. of lines in block Run time
600 0.36
1200 2.33
1800 5.77
2400 10.56
There seems to be a quadratic bottleneck in combine. distribute_notes has a loop that
goes over all previous instructions. distribute_notes calls reg_set_p, which calls set_of,
which calls note_stores, which calls set_of_1, which calls reg_overlap_mentioned_p,
which calls refers_to_regno_p... and all these show up quite at the top of the profile.
# of instructions function
224,203,200 rtlanal.c:refers_to_regno_p
150,433,200 rtlanal.c:reg_overlap_mentioned_p
75,561,636 rtlanal.c:note_stores
56,985,600 rtlanal.c:reg_referenced_p
49,576,316 regrename.c:validate_value_data
40,026,779 rtl.c:rtx_equal_p
28,740,658 flow.c:mark_set_1
27,562,800 combine.c:distribute_notes
25,928,400 rtlanal.c:set_of_1
15,840,000 rtlanal.c:reg_set_p
This might be a duplicate of PR13775.
--
Summary: combiner much slower on big functions
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
@ 2004-10-30 20:02 ` mmitchel at gcc dot gnu dot org
2004-10-30 20:03 ` mmitchel at gcc dot gnu dot org
` (8 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2004-10-30 20:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-30 20:02 -------
Postponed until GCC 3.4.4.
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.4.3 |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
2004-10-30 20:02 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks mmitchel at gcc dot gnu dot org
@ 2004-10-30 20:03 ` mmitchel at gcc dot gnu dot org
2004-11-15 12:11 ` ebotcazou at gcc dot gnu dot org
` (7 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2004-10-30 20:03 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-30 20:02 -------
Postponed until GCC 3.4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
2004-10-30 20:02 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks mmitchel at gcc dot gnu dot org
2004-10-30 20:03 ` mmitchel at gcc dot gnu dot org
@ 2004-11-15 12:11 ` ebotcazou at gcc dot gnu dot org
2004-11-16 8:05 ` ebotcazou at gcc dot gnu dot org
` (6 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2004-11-15 12:11 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15 12:11 -------
Investigating.
--
What |Removed |Added
----------------------------------------------------------------------------
CC|ebotcazou at gcc dot gnu dot|
|org |
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
` (2 preceding siblings ...)
2004-11-15 12:11 ` ebotcazou at gcc dot gnu dot org
@ 2004-11-16 8:05 ` ebotcazou at gcc dot gnu dot org
2004-11-16 8:22 ` ebotcazou at gcc dot gnu dot org
` (5 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2004-11-16 8:05 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-16 08:05 -------
> There has only been one patch to combine after 3.3 which might have caused
> this:
>
> 2003-10-06 Eric Botcazou <ebotcazou@libertysurf.fr>
>
> PR optimization/11637
> * combine.c (adjust_for_new_dest): New function to adjust the
> notes and LOG_LINKS when the dest of an insn has changed.
> (try_combine): Use it when deleting the first insn of a two-insn
> parallel or splitting a two-load parallel.
No, this patch is not responsible for the quadratic behaviour, which is still
present as of today on AMD64: reverting it doesn't change anything on mainline.
Digging a little further would have showed that the patch only adds a call to
distribute_links, not distribute_notes, which contains this comment:
Note that this correctly handles the link that used to point from
I3 to I2. Also note that not much searching is typically done here
since most links don't point very far away. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
` (3 preceding siblings ...)
2004-11-16 8:05 ` ebotcazou at gcc dot gnu dot org
@ 2004-11-16 8:22 ` ebotcazou at gcc dot gnu dot org
2004-11-16 8:24 ` ebotcazou at gcc dot gnu dot org
` (4 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2004-11-16 8:22 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-16 08:21 -------
And 5 minutes of additional work would have been sufficient to spot the obvious
culprit:
2003-05-14 Eric Christopher <echristo@redhat.com>
* combine.c: Fix header comments.
(distribute_notes): Remove usage of elim_i1, elim_i2. Propagate
to all calls and prototype.
containing most notably:
@@ -12550,19 +12530,14 @@ reg_bitfield_target_p (x, body)
as appropriate. I3 and I2 are the insns resulting from the combination
insns including FROM (I2 may be zero).
- ELIM_I2 and ELIM_I1 are either zero or registers that we know will
- not need REG_DEAD notes because they are being substituted for. This
- saves searching in the most common cases.
-
Each note in the list is either ignored or placed on some insns, depending
on the type of note. */
Reverting it makes the quadratic behaviour vanish on mainline.
It was backported between 3.3.2 and 3.3.3 by:
2003-12-16 Zack Weinberg <zack@codesourcery.com>
Backport the following patches from mainline.
[...]
2003-05-14 Eric Christopher <echristo@redhat.com>
* combine.c: Fix header comments.
(distribute_notes): Remove usage of elim_i1, elim_i2. Propagate
to all calls and prototype.
--
What |Removed |Added
----------------------------------------------------------------------------
Known to work|3.2.3 3.3 |3.2.3 3.3 3.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
` (4 preceding siblings ...)
2004-11-16 8:22 ` ebotcazou at gcc dot gnu dot org
@ 2004-11-16 8:24 ` ebotcazou at gcc dot gnu dot org
2004-11-18 20:46 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2004-11-16 8:24 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |echristo at redhat dot com
AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
` (5 preceding siblings ...)
2004-11-16 8:24 ` ebotcazou at gcc dot gnu dot org
@ 2004-11-18 20:46 ` pinskia at gcc dot gnu dot org
2004-12-07 19:54 ` echristo at redhat dot com
` (2 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-11-18 20:46 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-18 20:46 -------
Note on the mainline on PPC-darwin we are about twice as fast 1.5 seconds compared to 3.3 (3.2
seconds).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
` (6 preceding siblings ...)
2004-11-18 20:46 ` pinskia at gcc dot gnu dot org
@ 2004-12-07 19:54 ` echristo at redhat dot com
2004-12-22 19:23 ` steven at gcc dot gnu dot org
2004-12-22 19:48 ` echristo at redhat dot com
9 siblings, 0 replies; 22+ messages in thread
From: echristo at redhat dot com @ 2004-12-07 19:54 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From echristo at redhat dot com 2004-12-07 19:54 -------
The patch was put in to stop erroneous REG_DEAD notes from being created where
they shouldn't IIRC. Now, we may be able to rerun cfg as Paolo suggests, but I
don't know for certain. Unless we can prove that new speedups do the right thing
all the time I don't think we can put them back in - there was even a note in
the old code that we didn't always do the right thing.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
` (7 preceding siblings ...)
2004-12-07 19:54 ` echristo at redhat dot com
@ 2004-12-22 19:23 ` steven at gcc dot gnu dot org
2004-12-22 19:48 ` echristo at redhat dot com
9 siblings, 0 replies; 22+ messages in thread
From: steven at gcc dot gnu dot org @ 2004-12-22 19:23 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2004-12-22 19:23 -------
Perhaps someone can give an update on this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
` (8 preceding siblings ...)
2004-12-22 19:23 ` steven at gcc dot gnu dot org
@ 2004-12-22 19:48 ` echristo at redhat dot com
9 siblings, 0 replies; 22+ messages in thread
From: echristo at redhat dot com @ 2004-12-22 19:48 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From echristo at redhat dot com 2004-12-22 19:48 -------
I thought I did on the 7th. I'm not sure there's anything we can do about this.
The behavior is correct and the previous behavior was proved to be not correct.
If someone has an idea that's guaranteed to be correct in all cases I'm willing
to try to implement it though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2005-09-27 16:07 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20040130124106.13931.bonzini@gcc.gnu.org>
2005-01-14 14:31 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks steven at gcc dot gnu dot org
2005-01-15 6:11 ` pinskia at gcc dot gnu dot org
2005-01-15 7:31 ` echristo at redhat dot com
2005-01-15 12:25 ` steven at gcc dot gnu dot org
2005-01-15 16:23 ` pinskia at gcc dot gnu dot org
2005-01-28 18:50 ` ian at airs dot com
2005-05-19 17:26 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0/4.1 " mmitchel at gcc dot gnu dot org
2005-07-22 21:15 ` [Bug rtl-optimization/13931] [3.4/4.0/4.1 " pinskia at gcc dot gnu dot org
2005-07-25 3:09 ` pinskia at gcc dot gnu dot org
2005-09-27 5:11 ` ian at airs dot com
2005-09-27 5:33 ` ian at airs dot com
2005-09-27 16:10 ` mmitchel at gcc dot gnu dot org
2004-01-30 12:41 [Bug optimization/13931] New: combiner much slower on big functions bonzini at gnu dot org
2004-10-30 20:02 ` [Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks mmitchel at gcc dot gnu dot org
2004-10-30 20:03 ` mmitchel at gcc dot gnu dot org
2004-11-15 12:11 ` ebotcazou at gcc dot gnu dot org
2004-11-16 8:05 ` ebotcazou at gcc dot gnu dot org
2004-11-16 8:22 ` ebotcazou at gcc dot gnu dot org
2004-11-16 8:24 ` ebotcazou at gcc dot gnu dot org
2004-11-18 20:46 ` pinskia at gcc dot gnu dot org
2004-12-07 19:54 ` echristo at redhat dot com
2004-12-22 19:23 ` steven at gcc dot gnu dot org
2004-12-22 19:48 ` echristo at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).