https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126028
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's a complication in that we have
# hu_101 = PHI <hu_87(6), 0(3)>
...
_26 = (int) test0_82;
_27 = _26 + hu_101;
...
_31 = (int) test1_83;
_32 = _26 + _31;
hu_87 = _32 + hu_101;
with the intended reduction of hu_101 as BB root vectorizing from
{ _26 = (int) test0_82, _31 = (int) test1_83 }
but there's the use of the _26 = (int) test0_82 lane in the _27 = _26 + hu_101
statement. We fail to find an insertion
place for the lane-extract of _26 for the use in _27 = ... as we'll schedule
the vector stmt for (int) test* at the later _31 = (int) test1_83 statement,
so dominance will not work out. This makes the vectorization not profitable
since we're keeping the scalar computations producing _26.
There is the opportunity to change vector SLP scheduling or, at least for
live defs of unary operations, try to extract the source operand, keeping
only a single scalar stmt live.
Changing the source to do
int test0 = (r2_0 < groupplcutoff2);
int test1 = (r2_1 < groupplcutoff2);
re-scheduling the conversion in the scalar code mitigates this issue
and restores profitability.
