[Bug tree-optimization/103281] [9/10/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> The only thing which PHIOPT does is change:
>   if (c_15 == 0)
>     goto <bb 4>; [INV]
>   else
>     goto <bb 5>; [INV]
> 
>   <bb 4> :
> 
>   <bb 5> :
>   # iftmp.1_10 = PHI <0(4), c_15(3)>
> 
> to be:
> iftmp.1_10 = c_15;
> 
> This is a missed VRP:
>   # RANGE [0, 2] NONZERO 3
>   c_9 = (charD.10) b.4_5;
>   _1 = c_9 <= 0;
>   # RANGE [0, 1] NONZERO 1
>   _2 = (unsigned intD.14) _1;
>   if (_2 == b.4_5)

Note it just happens that iftmp.1_10 case of being 0 is the only that matters
to be "peeled" off and special cased.

Plus it just happens:
    char a = c ? c : c << 1;

Is hiding the relationship between a and c.

GCC does optimize if we change the loop to:
b >= 1 && b < 4

What we need to realize is that 0 needs to "peeled" off and tried seperately
with the range. that is the following two ranges need to be done seperately for
b.4_5:
[0, 0] [1, 2]
But how do GCC decides that is "hard".
we know the range of _1 to be [0,1] so we need to figure out the ranges of c_9
which cause 0 and which one causes 1.  This is not just a forward looking
alogrothim but need to look back really. It can be very computational
instensive too.