[Bug tree-optimization/102650] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #1 from Andrew Macleod <amacleod at redhat dot com> ---
This is a result of the vagaries of the single subrange value-range.

VRP is seeing:
# f_11 = PHI <-1(2), 2(3)>
  goto <bb 6>; [100.00%]

  <bb 5> [local count: 955630225]:
  _3 = (unsigned short) f_11;
  _6 = _3 + 2;
  e_19 = (short int) _6;

It knows f_11 is [-1, 2] and when that is cast to a ushort,  produces ~[3,
65534].

That is all we knew about it in GCC11, so when we calculate_6 = ~[3,65534] + 2 
it comes up with [1,4] and the e_19 == 0 later on then can be folded away.

in gcc12, EVRP has figured out that _3 is unsigned short [2, 2][+INF, +INF]. 
which if we add 2 to it, would come up with [1,1][4,4] which would be perfect.

We save this to the value_range global table in EVRP, but alas it gets
transliterated to a single pair value_range : _3  : unsigned short [2, +INF]

Now when VRP calculates ~[3, 65534] and intersects that with the known global
[2, +INF] the legacy intersect routine  has to come up with  pair and decides
to keep [2, +INF].  
when you add 2 to that, 0 is no longer eliminated.