There still are situations where we have stale LOG_LINKS. This causes combine to try two-insn combinations I2->I3 where the register set by I2 is used before I3 as well. Not good.
This patch fixes it by checking for this situation in can_combine_p (similar to what we already do for three and four insn combinations). Longer term we should make sure stale LOG_LINKS are removed (or moved), or ideally we should use DF instead of LOG_LINKS. I tested the patch on 31 architectures, no degradations seen. Zdenek tested it on the original testcase (thanks!) Committing to trunk. Segher 2018-03-12 Segher Boessenkool <seg...@kernel.crashing.org> PR rtl-optimization/84169 PR rtl-optimization/84780 * combine.c (can_combine_p): Check for a 2-insn combination whether the destination register is used between the two insns, too. --- gcc/combine.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/combine.c b/gcc/combine.c index c9105ed..06a9ddd 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -1990,6 +1990,7 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn *pred ATTRIBUTE_UNUSED, && (reg_used_between_p (dest, succ2, i3) || reg_used_between_p (dest, succ, succ2))) || (!succ2 && succ && reg_used_between_p (dest, succ, i3)) + || (!succ2 && !succ && reg_used_between_p (dest, insn, i3)) || (succ /* SUCC and SUCC2 can be split halves from a PARALLEL; in that case SUCC is not in the insn stream, so use SUCC2 -- 1.8.3.1