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

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

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com
           Priority|P3                          |P1
   Last reconfirmed|                            |2022-02-14
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems like something EVRP should optimize.

The pre- r12-6924 IL was:
  c.0_1 = c;
  _2 = *c.0_1;
  # RANGE [-1, 1]
  _3 = 1 / _2;
  # RANGE [1, 2] NONZERO 3
  d_11 = 2 >> _3;
and evrp properly figured out those ranges, that 1 / int is [-1, 1] and
that 2 >> [-1, 1] is [1, 2].
But since r12-6924 the IL is:
  c.0_1 = c;
  _2 = *c.0_1;
  _11 = (unsigned int) _2;
  _12 = _11 + 1;
  _13 = _12 <= 2;
  _3 = _12 <= 2 ? _2 : 0;
  # RANGE [0, 2] NONZERO 3
  d_14 = 2 >> _3;
and the range for d_14 is too broad (includes 0) and no ranges are recorded for
the other SSA_NAMEs.
Now, __1 and _12 are of course VARYING, and because _13 is _Bool, it is also
VARYING.
The important missing part is that we don't realize that _12 <= 2 ? _2 : 0
implies [-1, 1] range.  The _2 + 1U <= 2U is a standard pattern how ranges are
encoded.  Now if I rewrite the testcase by hand to:
void foo(void);

static int a, b = 1, *c = &b;
int main() {
  for (; a; a--) {
    int e;
    int ct = *c;
    if (ct + 1U <= 2U)
      e = ct;
    else
      e = 0;
    int d = 2 >> e;
    if (!d)
      foo();
  }
}
which is equivalent to doing the 1 / int PR95424 optimization by hand, but
instead of having it in a COND_EXPR do it in separate bbs, i.e.:
  c.0_1 = c;
  ct_12 = *c.0_1;
  ct.1_2 = (unsigned int) ct_12;
  _3 = ct.1_2 + 1;
  if (_3 <= 2)
    goto <bb 5>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 4> :

  <bb 5> :
  # RANGE [-1, 1]
  # e_7 = PHI <ct_12(3), 0(4)>
  # RANGE [1, 2] NONZERO 3
  d_15 = 2 >> e_7;
then evrp handles it just fine.

So, Andrew/Aldy, how hard would it be to improve ranger COND_EXPR handling, so
that it essentially does what we do for the PHI cases?  I.e. from the COND_EXPR
condition, compute "assertion" if condition is true or if condition is false,
and use that on the COND_EXPR's second and third argument.
So for the
  _3 = _12 <= 2 ? _2 : 0;
comparison, for second argument the condition must be true which implies that
_2 must be there [-1, 1], while for the third argument the condition must be
false, but the argument is constant 0, so range is [0, 0], then just union
those 2 ranges.

As this is a P1 regression, if we can fix it, would be nice to get it into GCC
12.