[Bug tree-optimization/57755] Improve fold_binary_op_with_conditional_arg

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> I think we should optimize this testcases slightly different from
> "improving" fold_binary_op_with_conditional_arg (I think
> fold_binary_op_with_conditional_arg 
>  should go away even but that is a different story).
> 
> Let's start with:
> ```
> int f(int a,int b){
>   return (((a<=3)?-1:0)&((b<=2)?-1:0))!=0;
> }
> ```
> After ccp1 we have:
>   # iftmp.1_4 = PHI <-1(4), 0(5)>
>   _1 = iftmp.0_3 & iftmp.1_4;
> 
> But really that should just become:
> # _1 = PHI <iftmp.0_3(4), 0(5)>
> 
> PRE does that but that is way too late.

Actually another way of fixing the above is we have in forwprop3:
  _14 = a_5(D) <= 3;
  _17 = (int) _14;
  _18 = -_17;
  _9 = b_6(D) <= 2;
  _12 = (int) _9;
  _1 = _12 * _18;
  _2 = _1 != 0;
  _7 = (int) _2;

Well we can see (_12 * _18) != 0 is really _12 != 0 & _18 != 0 which can be
done easier as _12 has a range of [0,1].

If we do that then in forwprop3 we get:
  _9 = b_6(D) <= 2;
  _3 = a_5(D) <= 3;
  _2 = _3 & _9;
  _7 = (int) _2;

which what we want ...

That is that transformation is what we have in bug 110992 comment #9 . the
reason for the check of [0,1] is that we know there would be no overflows and
can be safely done no matter what.