[Bug tree-optimization/105086] [12 Regression] Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
Ranger VRP doesn't simulate edges the same way VRP does. It looks like VRP
simulates the back edge twice and the second time notes that the MAX value is
greater than it was before and "projects" the max to +INF to avoid further
simulations and thus executing every instance of the loop. 

This allows it to refine the range in the loop better, which ranger VRP isn't
doing as it is still doing a DOM walk and doesn't revisit the node. ANd I
haven't added any sort of similar "projection" logic to the back edge
processing.

I have an alternate question.  it looks like when we utilize scev to pick up
ranges we just give up if scev_probably_wraps_p() is true.

Analyzing # of iterations of loop 1
  exit condition 1 < [4294967273, + , 1]
  bounds on difference of bases: 4294967272 ... 4294967272
  result:
    # of iterations 23, bounded by 23

Statement (exit)if (a_1 > 1)
is executed at most 23 (bounded by 23) + 1 times in loop 1.

but we neglect to create range for the PHI. We should be able to properly
create a  range for this from the SCEV info rather than giving up?  It would be
[0,0][4294967273, 4294967295]. 

And even with the old value_range we could use anti-range and produce
~[1, 4294967272]?

Is there a practical reason we don't look any closer at wrap cases to see if
they are "simple wraps" or not?  I think that would also solve this issue.