https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> --- So there is a sink difference in the loop which sets extent[n]. Before we had: ``` extent[n_207] = _20; if (_20 < 0) goto <bb 5>; [41.00%] else goto <bb 6>; [59.00%] <bb 5> [local count: 48082917]: extent[n_207] = 0; <bb 6> [local count: 117275410]: ``` But after we get: ``` if (_20 < 0) goto <bb 6>; [41.00%] else goto <bb 5>; [59.00%] <bb 5> [local count: 69192492]: extent[n_207] = _20; goto <bb 7>; [100.00%] <bb 6> [local count: 48082917]: extent[n_207] = 0; <bb 7> [local count: 117275410]: ``` This is ok and fine. The difference is how ifcvt handles the loop: _250 = MAX_EXPR <_20, 0>; _ifc__174 = _250; extent[n_207] = _ifc__174; vs: _102 = _20 < 0; _173 = &extent[n_207]; .MASK_STORE (_173, 64B, _102, 0); _174 = _20 >= 0; .MASK_STORE (_173, 64B, _174, _20); And then the loop is vectorized in a kinda of odd way and I am not 100% sure if it gets vectorized correctly. So there is at least a missed optimization here ...