From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2136) id 7877A3857036; Mon, 5 Sep 2022 06:23:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7877A3857036 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662359016; bh=poIPpoiKBZAs4+xYd9Wicd98L3X6SNQ+sKVrBn7Ttcw=; h=From:To:Subject:Date:From; b=MavJWFSgBhCetx/cNxHfxaykTjXKYdf2WUr1TdKAyxQqmopjq0LUjIWVlhSqtIEgk xvgatpMDsDJfaHByC5PuDTVhMfQ4Zg8XGwLmpfb7OzKYXnTenYVCQJ6U8TBHluUYyA doI7lw0FZJ5t2q8uMrz4okHSKx6yF9CVQ5bS4OH8= MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" From: Aldy Hernandez To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-2399] Be even more conservative in intersection of NANs. X-Act-Checkin: gcc X-Git-Author: Aldy Hernandez X-Git-Refname: refs/heads/master X-Git-Oldrev: 5e070cf4bd085e10601195bb223dd1a0edeecf4d X-Git-Newrev: 5f3228935e27780430a8a1504c2fa4a1ff978594 Message-Id: <20220905062336.7877A3857036@sourceware.org> Date: Mon, 5 Sep 2022 06:23:36 +0000 (GMT) List-Id: https://gcc.gnu.org/g:5f3228935e27780430a8a1504c2fa4a1ff978594 commit r13-2399-g5f3228935e27780430a8a1504c2fa4a1ff978594 Author: Aldy Hernandez Date: Sun Sep 4 21:21:32 2022 +0200 Be even more conservative in intersection of NANs. Intersecting two ranges where one is a NAN is keeping the sign bit of the NAN range. This is not correct as the sign bits may not match. I think the only time we're absolutely sure about the intersection of a NAN and something else, is when both are a NAN with exactly the same properties (sign bit). If we're intersecting two NANs of differing sign, we can decide later whether that's undefined or just a NAN with no known sign. For now I've done the latter. I'm still mentally working on intersections involving NANs, especially if we want to keep track of signbits. For now, let's be extra careful and only do things we're absolutely sure about. Later we may want to fold the intersect of [NAN,NAN] and say [3,5] with the posibility of NAN, to a NAN, but I'm not 100% sure. As I've said before, setting varying is always a safe choice, because it means we know nothing and ranger won't attempt to optimize anything. gcc/ChangeLog: * value-range.cc (early_nan_resolve): Remove. (frange::intersect): Handle NANs. Diff: --- gcc/value-range.cc | 35 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/gcc/value-range.cc b/gcc/value-range.cc index c9f42fe272c..9c561415971 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -444,24 +444,6 @@ frange::normalize_kind () return false; } -// If both operands are definitely NAN, do nothing as they combine -// perfectly. If OTOH, only one is a NAN, set R to VARYING as they -// can't be neither unioned nor intersected. Return TRUE if we -// changed anything. - -static inline bool -early_nan_resolve (frange &r, const frange &other) -{ - gcc_checking_assert (r.get_nan ().yes_p () || other.get_nan ().yes_p ()); - - // There's nothing to do for both NANs. - if (r.get_nan ().yes_p () == other.get_nan ().yes_p ()) - return false; - // ?? Perhaps the intersection of a NAN and anything is a NAN ??. - r.set_varying (r.type ()); - return true; -} - bool frange::union_ (const vrange &v) { @@ -532,8 +514,23 @@ frange::intersect (const vrange &v) *this = r; return true; } + + // If two NANs are not exactly the same, drop to an unknown NAN, + // otherwise there's nothing to do. + if (get_nan ().yes_p () && r.get_nan ().yes_p ()) + { + if (m_props == r.m_props) + return false; + + *this = frange_nan (m_type); + return true; + } + // ?? Perhaps the intersection of a NAN and anything is a NAN ??. if (get_nan ().yes_p () || r.get_nan ().yes_p ()) - return early_nan_resolve (*this, r); + { + set_varying (m_type); + return true; + } bool changed = m_props.intersect (r.m_props);