https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
--- Comment #5 from Robin Dapp <rdapp at gcc dot gnu.org> ---
So the result is -9 instead of 9 (or vice versa) and this happens (just) with
vectorization. We only vectorize with -fwrapv.
>From a first quick look, the following is what we have before vect:
(loop)
<bb 3> [local count: 991171080]:
...
# b_lsm.5_5 = PHI <_4(7), b_lsm.5_17(2)>
...
_4 = -b_lsm.5_5;
(check)
<bb 4> [local count: 82570744]:
...
# b_lsm.5_22 = PHI <b_lsm.5_5(3)>
...
if (b_lsm.5_22 != -9)
I.e. b gets negated with every iteration and we check the second to last
against -9.
With vectorization we have:
(init)
<bb 2> [local count: 82570744]:
b_lsm.5_17 = b;
(vectorized loop)
<bb 3> [local count: 247712231]:
...
# b_lsm.5_5 = PHI <_4(7), b_lsm.5_17(2)>
...
_4 = -b_lsm.5_5;
...
goto <bb 3>
(epilogue)
<bb 10> [local count: 82570741]:
...
# b_lsm.5_7 = PHI <_25(11), b_lsm.5_17(13)>
...
_25 = -b_lsm.5_7;
(check)
<bb 4> [local count: 82570744]:
...
# b_lsm.5_22 = PHI <b_lsm.5_7(10)>
if (b_lsm.5_22 != -9)
What looks odd here is that b_lsm.5_7's fallthrough argument is b_lsm.5_17 even
though we must have come through the vectorized loop (which negated b at least
once). This makes us skip inversions.
Indeed, as b_lsm.5_22 is only dependent on the initial value of b it gets
optimized away and we compare b != -9.
Maybe I missed something but it looks like
# b_lsm.5_7 = PHI <_25(11), b_lsm.5_17(13)>
should have b_lsm.5_5 or _4 as fallthrough argument.
