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 ...