https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101025
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is with sm_seq_valid_bb which when processing store sequences from
multiple branches of the CFG performs merging in a way that drops refs
that still need to be considered for dependence queries. Notably
/* Incrementally merge seqs into first_edge_seq. */
for (unsigned int i = 0; i < min_len; ++i)
{
/* ??? We can more intelligently merge when we face
different
order by additional sinking operations in one sequence.
For now we simply mark them as to be processed by the
not order-preserving SM code. */
if (first_edge_seq[i].first != edge_seq[i].first)
{
if (first_edge_seq[i].second == sm_ord)
bitmap_set_bit (refs_not_supported,
first_edge_seq[i].first);
if (edge_seq[i].second == sm_ord)
bitmap_set_bit (refs_not_supported, edge_seq[i].first);
first_edge_seq[i].second = sm_other;
first_edge_seq[i].from = NULL_TREE;
we re matching f ={v} 0 against a[3] = ...;, marking 'f' as not supported for
store-motion and to be dependence checked against all stores in the sequence.
But we simply forget about a[3] = ... which we'd need to insert somehow into
the sequence for dependence checking purposes similar to how we handle
/* Any excess elements become sm_other since they are now
coonditionally executed. */
if (first_edge_seq.length () > edge_seq.length ())
{
(but even that code looks suspicious). What we'd need to verify is that
we can push the ref down in 'edge_seq' (but not actually do that) and then
append it like the late loop (but we need to disambiguate against the
stores in first_edge_seq as well).
The code is quite complex and as it handles dependence queries incrementally
it's also fragile...
