[Bug tree-optimization/103723] zero extend not moved out of the loop after IV-OPTS

["pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103723

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-12-15
            Summary|Loop invariant motion pass  |zero extend not moved out
                   |failed to remove unused     |of the loop after IV-OPTS
                   |code from loop              |
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Severity|normal                      |enhancement

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>For this case, the instruction  `mov     ecx, eax` in bb `.L3` could remove from loop body and could sink to '.L8' and '.L1'.

Right the problem is not what you referenced in the comment #0 though, it is
the following instead:
  _4 = (unsigned int) ivtmp.7_15;

That is a truncate from 64bit to 32bit.
There is no pass after IV-OPTS that sinks the zero extend out of the loop
though. LIM on the gimple level is not doing it for some reason ...

At Lim4 we have:
  <bb 4> [local count: 1014686026]:
  # ivtmp.7_15 = PHI <ivtmp.7_7(7), 2(6)>
  _4 = (unsigned int) ivtmp.7_15;
  len_test_13 = _4;
  _3 = MEM[(const uint8_t *)buf_9(D) + ivtmp.7_15 * 1];
  _6 = MEM[(const uint8_t *)buf_back_11(D) + ivtmp.7_15 * 1];
  if (_3 == _6)
    goto <bb 3>; [94.50%]
  else
    goto <bb 10>; [5.50%]

  <bb 10> [local count: 55807731]:
  # len_test_16 = PHI <len_test_13(4)>

I don't know enough about LIM if it was designed to handle non stores to sink
but maybe it should.