The PR claims that pair-fusion has invalid uses of gcc_assert (such that
the pass will misbehave with --disable-checking). As noted in the
comments, in the case of the calls to restrict_movement, the only way we
can possibly depend on the side effects is if we call it with a
non-singleton move range. However, the intent is that we always have a
singleton move range here, and thus we do not rely on the side effects.
This patch therefore adds asserts to check for a singleton move range
before calling restrict_movement, thus clarifying the intent and
hopefully dispelling any concerns that having the calls wrapped in
asserts is problematic here.
Tested on aarch64-linux-gnu, pushed to trunk.
Alex
gcc/ChangeLog:
PR rtl-optimization/114492
* pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Check for singleton
move range before calling restrict_movement.
(pair_fusion::try_promote_writeback): Likewise.
diff --git a/gcc/pair-fusion.cc b/gcc/pair-fusion.cc
index 72e64246534..a4ef7287967 100644
--- a/gcc/pair-fusion.cc
+++ b/gcc/pair-fusion.cc
@@ -1994,7 +1994,8 @@ pair_fusion_bb_info::fuse_pair (bool load_p,
auto ignore = ignore_changing_insns (changes);
for (unsigned i = 0; i < changes.length (); i++)
- gcc_assert (rtl_ssa::restrict_movement (*changes[i], ignore));
+ gcc_assert (changes[i]->move_range.singleton ()
+ && rtl_ssa::restrict_movement (*changes[i], ignore));
// Check the pair pattern is recog'd.
if (!rtl_ssa::recog (attempt, *pair_change, ignore))
@@ -3084,7 +3085,8 @@ pair_fusion::try_promote_writeback (insn_info *insn, bool
load_p)
auto ignore = ignore_changing_insns (changes);
for (unsigned i = 0; i < ARRAY_SIZE (changes); i++)
- gcc_assert (rtl_ssa::restrict_movement (*changes[i], ignore));
+ gcc_assert (changes[i]->move_range.singleton ()
+ && rtl_ssa::restrict_movement (*changes[i], ignore));
if (!rtl_ssa::recog (attempt, pair_change, ignore))
{
