So it turns out LOOPS_MAY_HAVE_MULTIPLE_LATCHES is set in places
along compiling. Setting it only means there might be multiple
latches currently. It does not mean let's go in an delete them
all; which is what remove_forwarder_block does currently. This
was happening before my set of patches too but since it was
only happening in merge_phi pass, latches were not cleared away
al of the time and then recreated.
This solves the problem by protecting latches all of the time
instead of depedent on LOOPS_MAY_HAVE_MULTIPLE_LATCHES not being set.
vect-uncounted_7.c needs to be xfailed here because we no longer
vectorize the code. Note the IR between GCC 15 and after this patch
is the same so I think this was just a case were the testcase
was added after the remove forwarder changes and should not have
vectorized (or vectorize differently).
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/123417
gcc/ChangeLog:
* tree-cfgcleanup.cc (maybe_remove_forwarder_block): Always
protect latches.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-uncounted_7.c: xfail vect test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
}
}
-/* { dg-final { scan-tree-dump "Loop being analyzed as uncounted." "vect" } } */
-/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" } } */
+/* { dg-final { scan-tree-dump "Loop being analyzed as uncounted." "vect" } } */
+/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" { xfail *-*-* } } } */
return false;
/* If bb doesn't have a single predecessor we'd make this
loop have multiple latches. Don't do that if that
- would in turn require disambiguating them. */
- if (!single_pred_p (bb)
- && !loops_state_satisfies_p
- (LOOPS_MAY_HAVE_MULTIPLE_LATCHES))
+ would in turn require disambiguating them over again. */
+ if (!single_pred_p (bb))
return false;
}
/* cleanup_tree_cfg_noloop just created the loop preheader, don't