]> git.ipfire.org Git - thirdparty/gcc.git/commit
recog: Avoid validate_change shortcut for groups [PR115782]
authorRichard Sandiford <richard.sandiford@arm.com>
Thu, 11 Jul 2024 13:44:11 +0000 (14:44 +0100)
committerRichard Sandiford <richard.sandiford@arm.com>
Thu, 11 Jul 2024 13:44:11 +0000 (14:44 +0100)
commit44fc801e97a8dc626a4806ff4124439003420b20
tree15834cb3caaffaf12bc832919eee6d2514b88466
parentb9513c6746bfdbbb2f5e2a52bc3504236692beeb
recog: Avoid validate_change shortcut for groups [PR115782]

In this PR, due to the -f flags, we ended up with:

bb1:  r10=r10
...
bb2:  r10=r10
...
bb3:  ...=r10

with bb1->bb2 and bb1->bb3.

late-combine successfully combined the bb1->bb2 def-use and set
the insn code to NOOP_MOVE_INSN_CODE.  The bb1->bb3 combination
then failed for... reasons.  At this point, everything should have
been rewound to its original state.

However, substituting r10=r10 into r10=r10 gives r10=r10, and
validate_change had an early-out for no-op rtl changes.  This meant
that validate_change did not register a change for the bb2 insn and
so did not save its old insn code.  The NOOP_MOVE_INSN_CODE therefore
persisted even after the attempt had been rewound.

IMO it'd be too cumbersome and error-prone to expect all users of
validate_change to be aware of this possibility.  If code is using
validate_change with in_group=1, I think it has a reasonable expectation
that a change will be registered and that the insn code will be saved
(and restored on cancel).  This patch therefore limits the shortcut
to the !in_group case.

gcc/
PR rtl-optimization/115782
* recog.cc (validate_change_1): Suppress early exit for no-op
changes that are part of a group.

gcc/testsuite/
PR rtl-optimization/115782
* gcc.dg/pr115782.c: New test.
gcc/recog.cc
gcc/testsuite/gcc.dg/pr115782.c [new file with mode: 0644]