[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
There are two things needed to fix this regression.

First, we need an op1_range entry for bitwise-and, so that the 2->4 edge range
has the correct nonzero bits for n_12.

    <bb 2> [local count: 118111600]:
    _1 = n_12(D) & 7;
    if (_1 != 0)
      goto <bb 3>; [0.00%]
    else
      goto <bb 4>; [100.00%]

With the correct tweak to range-ops, we have:

2->4  (F) n_12(D) :     [irange] size_t [1, 18446744073709551608] NONZERO
0xfffffffffffffff8

Which is correct and what DOM would need from ranger to get the nonzero mask
correct.

However, set_global_ranges_from_unreachable_edges() in DOM is is only exporting
ranges for unreachable edges on the SSA names feeding the final conditional
above (_1).  It also needs to calculate these ranges for other exports from
this BB.  In this case, we'd need to do the same thing for n_12 as well as _1.

In my conversion of DOM+evrp to DOM+ranger, I missed that evrp was doing this
dance for all the ranges it knew about coming out of the BB, not just op1 of
the conditional.  This is legacy evrp:

          /* Push updated ranges only after finding all of them to avoid
             ordering issues that can lead to worse ranges.  */
          for (unsigned i = 0; i < vrs.length (); ++i)
...
...
              if (is_fallthru
                  && m_update_global_ranges
                  && all_uses_feed_or_dominated_by_stmt (vrs[i].first, stmt)
                  /* The condition must post-dominate the definition point.  */
                  && (SSA_NAME_IS_DEFAULT_DEF (vrs[i].first)
                      || (gimple_bb (SSA_NAME_DEF_STMT (vrs[i].first))
                          == pred_e->src)))
                {
                  set_ssa_range_info (vrs[i].first, vrs[i].second);
                  maybe_set_nonzero_bits (pred_e, vrs[i].first);
                }

All we'd need in theory is to loop over the exports to BB2, and export those if
the same logic applies.  

I have two patches in testing that fix the regression.