[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[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]

-- 
           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

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[pinskia at gcc dot gnu dot org]

------- 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

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[echristo at redhat dot com]

------- 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

[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]

------- 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

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[pinskia at gcc dot gnu dot org]

------- 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

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[ian at airs dot com]

------- 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

[Bug rtl-optimization/13931] [3.3/3.4/4.0/4.1 Regression] combiner much slower on big basic blocks

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.4                       |3.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931

[Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks

[pinskia at gcc dot gnu dot org]

------- 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

[Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks

[pinskia at gcc dot gnu dot org]

------- 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

[Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks

[ian at airs dot com]

------- 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

[Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks

[ian at airs dot com]

------- 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

[Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931