From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117418 invoked by alias); 13 Oct 2019 16:29:04 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 117410 invoked by uid 89); 13 Oct 2019 16:29:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Takes, only, HTo:U*aldyh, settle X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 13 Oct 2019 16:29:03 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D59CD5AFE3 for ; Sun, 13 Oct 2019 16:29:01 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-67.rdu2.redhat.com [10.10.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id C7D7F5D6A3; Sun, 13 Oct 2019 16:29:00 +0000 (UTC) Subject: Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0] To: Aldy Hernandez Cc: gcc-patches , Andrew MacLeod References: <995b4560-6a76-6742-888f-eadbfb9ff9cc@redhat.com> <74fb2cf8-6312-6ae2-b620-3d36deb61080@redhat.com> <6a557c4c-d86b-7b7f-70c2-483fff2d5f59@redhat.com> <4a1ab265-cd1d-71b3-c2c7-31cd3667fa54@redhat.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Sun, 13 Oct 2019 16:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <4a1ab265-cd1d-71b3-c2c7-31cd3667fa54@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00950.txt.bz2 On 10/7/19 6:28 AM, Aldy Hernandez wrote: > > Fair enough.  I guess I don't care what we settle on, inasmuch as we > canonicalize into one true value.  For some reason, I thought the above > nonzero would cause you to cringe, I guess not :). :-) Takes more than that these days.. And just to reiterate for the larger audience what we discussed in IRC -- I'm absolutely for canonicalization. We're just debating what the canonical form should be and how to get there. > > Happily, normalizing into ~0 for signed and [1,MAX] for unsigned, > simplified the patch because it on longer needs tweaks to > ranges_from_anti_range. Looks like it was ultimately far smaller than I expected. Unless we haven't audited existing code looking for open-coded ~[0,0] tests. > > OK for trunk? With a ChangeLog, yes. > > Aldy > > p.s. This still leaves open the issue with ipa_vr's handling of > nonzero_p.  As per my last message, I've adjusted it to check for either > ~[0,0] or the [1,MAX] variant for unsigned, since before this patch > there were two ways of representing the same thing.  However, ipa-prop > has no API (it open codes everything), as it has rolled its own version > of "value ranges" with wide-ints. > > class GTY(()) ipa_vr > { > public: >   /* The data fields below are valid only if known is true.  */ >   bool known; >   enum value_range_kind type; >   wide_int min; >   wide_int max; >   bool nonzero_p (tree) const; > }; > > I'm tempted to leave the nonzero_p which checks for both ~0 and [1,MAX]: > > bool > ipa_vr::nonzero_p (tree expr_type) const > { >   if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p (max, 0)) >     return true; > >   unsigned prec = TYPE_PRECISION (expr_type); >   return (type == VR_RANGE >       && TYPE_UNSIGNED (expr_type) >       && wi::eq_p (min, wi::one (prec)) >       && wi::eq_p (max, wi::max_value (prec, TYPE_SIGN (expr_type)))); > } > > I don't care either way. Sigh. I can live with either here as well. I'm hesitant to start mucking around with it simply because it's well outside of where we've got expertise. jeff