[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