[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #48 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
for PHIs with 3+ arguments unless all the arguments but one are the same even
when not doing any smarts seems we emit one more COND_EXPR from what we could.
The
      /* Common case.  */
case loop emits args_len COND_EXPRs, where to select one of the args_len
values, one should need only args_len - 1 COND_EXPRs.
So e.g. for the #c47 first testcase, we emit:
  _7 = a_10 < 0;
  _21 = a_10 >= 0;
  _22 = a_10 < e_11(D);
  _23 = _21 & _22;
  _26 = a_10 >= e_11(D);
  _27 = _21 & _26;
  _ifc__42 = _7 ? 1 : t_13;
  _ifc__43 = _23 ? t_13 : _ifc__42;
  t_6 = _27 ? 0 : _ifc__43;
Even when not trying to be smart on which predicate goes first and which goes
last (currently we only make sure that argument with most duplicates gets
last), I don't see why we should emit args_len COND_EXPRs, if we check just the
last args_len - 1 predicates or first args_len - 1 predicates, when all the
predicates are false it should represent the argument that wasn't otherwise
picked.  So, the above without smart optimizations IMHO could be either
replaced with
  _ifc__42 = _23 ? t_13 : 1;
  t_6 = _27 ? 0 : _ifc__42;
or
  _ifc__42 = _23 ? t_13 : 0;
  t_6 = _7 ? 1 : _ifc__42;
etc.
But we really should also do the smart optimization, see through the
bb_predicates which one is BIT_AND_EXPRed with inversion of some other arg's
predicate and avoid those BIT_AND_EXPRs and redundant comparisons by sorting
them better.