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

Reply via email to