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.
