[Bug tree-optimization/105276] [12 Regression] executed once loop not optimized anymore

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
                 CC|                            |amacleod at redhat dot com,
                   |                            |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-04-20

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r12-5688-gcb137e85720654e41db370d952df226654e576a6
The difference starts in vrp2, where the actual IL change is:
-  _5 = (bool) i_16;
-  _12 = i_16;
+  _5 = i_16 != 0;
+  _12 = (unsigned int) _5;
and the ranges changes are:
-i_1  : unsigned int [0, 1]
+i_1  : unsigned int [0, 2]
 i_7  : unsigned int [0, 2]
-i_8  : unsigned int [0, 1][+INF, +INF]
+i_8  : unsigned int [0, 2][+INF, +INF]
 _12  : unsigned int [0, 1]
 i_13  : unsigned int [1, +INF]
-i_14  : unsigned int [1, 1][+INF, +INF]
-i_16  : unsigned int [0, 1]
+i_14  : unsigned int [1, 2][+INF, +INF]
+i_16  : unsigned int [0, 2]
The old ranges were narrower and I think correct.
  i_7 = i_13 % 3;
...
  if (i_7 != 2)
...
  # i_16 = PHI <i_7(3), i_1(5)>
  _5 = i_16 != 0;
  _12 = (unsigned int) _5;
  i_8 = i_16 - _12;
  if (i_8 != 0)
...
  # i_14 = PHI <i_8(4)>
  i_1 = i_14 % 3;
Now, that
  i = i % 3;
  (i==2 ? 2 : i ? 1 : 0)
in the source is just an obfuscated way of saying i = i % 3; i
so obviously the loop will iterate at most once (0 times if i is 0, otherwise
there will be i = i - i; and it will be zero at the end of the first
iteration).
That is something the ranger doesn't need to decipher obviously, but the
above means i_7 is [0, 2], on i_16 PHI i_7 is known to be [0, 1], so assuming
it comes from that edge, i_8 is [0, 1][+INF, +INF] aka ~[2, 0xfffffffe],
for 0 it doesn't even jump to i_14 PHI (but 0 % 3 is 0), for i_14 == 1 is 1 % 3
1 and for i_14 == -1U is -1U % 3 == 0.  So, i_1 is in [0, 1] range and loops,
so the original assumptions that i_16 is [0, 1] don't change.