https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77387
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-08-26
Version|unknown |6.1.0
Summary|Value range not computed in |-Wstrict-overflow
|some cases for ABS_EXPR |pessimizes VRP in some
| |cases for ABS_EXPR
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, it arrives at
x_3: [0, +INF(OVF)]
to be able to diagnose -Wstrict-overflow. This means that further ops on
such range are "restricted" (that +INF(OVF) maximum is "sticky"). Not my
favorite way of things but this is how it is designed. Your patch breaks
that.
We're getting the above range from extract_range_basic - arguably ABS
handling could be improved directly here, most simply by instead of
feeding VARYING to the workers, feed [-MIN, +MAX] to them. Though then
we need to be careful to never canonicalize [-MIN, +MAX] to VARYING,
otherwise we'll eventually iterate between the (OVF) and non-(OVF) variants,
another possibility would be to feed [-MIN(OVF), +MAX(OVF)] for VARYING
and !TYPE_OVERFLOW_WRAPS.
That said, finally getting rid of that (OVF) stuff entirely from VRP would
be very very very welcome ;) For -Wstrict-overflow simply do ssa_propagate
twice, once with -fwrapv and once with -fno-wrapv, then for all substitutions
and simplifications see if the outcome is different and _then_ warn (ok,
that "see if the outcome is different" might be quite interesting to
implement).
So - the result of the testcase is as designed. We can improve x_4 to [0,
+INF(OVF)] at most, we fail to do this because +INF(OVF) >> 24 "overflows"
in extract_range_from_multiplicative_op_1. The fallback is to drop to VARYING
but dependent on 'code' we could drop to VR0 here. Not that this helps the
testcase.
Note the inability to simplify is just so we can get -Wstrict-overflow
warnings (there are a few other missed-optimization PRs because of the same
reason).
