Re: [PATCH 6/6] combine: allow combining two insns into two in some cases (PR52714)

[Segher Boessenkool <segher at kernel dot crashing dot org>]

On Wed, Dec 03, 2014 at 05:31:15PM +0800, Bin.Cheng wrote:
> Does your series of patches affect PR62151?  I am going to revisit
> that one to see if I can answer Jeff's questions there.

I don't think any of my recent patches affects it.  r215789 does,
however, so you'll need to revert that to show the problem again.

To recap:
We have five insns, call them A, B, C, D, E.  A feeds B feeds C;
C feeds both D and E.  A and C set the same pseudo.  D and E are
simple moves.

A+B+C would not combine because of a limitation that r215789 removed.
Then combine tried combining A+B+C+D doing effectively the combination
of A+B+C, and un-cse'ing the result to D.  Then distribute_notes
messes up with the REG_DEAD note of B (the result of A is dead); it
takes it to mean the result of C is dead, but E still uses that.

r215789 hides this in the cases where A+B+C in fact combines, which
in practice is (nearly) all cases.  Either we need to fix
distribute_notes, or we should disallow A->B->C->D combos where the
result of C is not dead at D, to fix this for real.  I vote for the
latter: 4-insn combine is expensive, and doesn't often improve anything,
and it's even less likely to match anything in this case (which after
all needs to keep the result of A+B+C around, even though that on its
own did not combine!)  Even if it matches, it in effect does an uncse
which combine does not normally do; it would be better to do that in
a separate pass (maybe piggyback it on fwprop, its sibling; or maybe
do it separately.  Something for the future, anyway).


Segher