PING
On 9/17/18 6:12 AM, Aldy Hernandez wrote:
It seems most of the remaining anti range code in
extract_range_from_unary_expr for CONVERT_EXPR_P is actually dealing
with non-nullness in practice.
Anti-range handling is mostly handled by canonicalizing anti-ranges into
its two set constituents (~[10,20] => [MIN,9] U [21,MAX]) and dealing
with them piece-meal. For that matter, the only way we can reach the
conversion code in extract_range_from_unary_expr with an anti-range is
either with a pointer (because pointers are ignored from
ranges_from_anti_range on purpose), or when converting integers of the
form ~[SSA, SSA]. I verified this with a bootstrap + tests with some
specially placed asserts, BTW.
So... if we special handle pointer conversions (both to and fro, as
opposed to just to), we get rid of any anti-ranges with the exception of
~[SSA, SSA] between integers. And anti-ranges of unknown quantities
(SSAs) will be handled automatically already (courtesy of
extract_range_into_wide_ints).
I propose we handle pointers at the beginning, and everything else just
falls into place, with no special code.
As commented in the code, this will pessimize conversions from (char
*)~[0, 2] to int, because we will forget that the range can also not be
1 or 2. But as Jeff commented, we really only care about null or
non-nullness. Special handling magic pointers with constants IMO is a
wasted effort. For that matter, I think it was me that added this
spaghetti a few weeks ago to make sure we handled ~[0,2]. We weren't
even handling it a short while back :-). Furthermore, in a bootstrap, I
think we only triggered this twice. And I'm not even sure we make
further use of anything null/not-null for pointers later on.
This patch simplifies the code, and removes more special handling and
cryptic comments related to anti-ranges.
Tested with all languages including Ada and Go.
OK for trunk?
