From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 8707A3858423 for ; Fri, 3 Feb 2023 20:13:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8707A3858423 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675455202; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-to: resent-from:resent-message-id:in-reply-to:in-reply-to: references:references; bh=VWb4EEBKOtyuHe4svr1J5/+Q1gJMNq7uzFpqDhXLqYg=; b=J5J2aBAGEf0cShUlmjYtcEM1i343e91dtU/3WcVBbIKEEDRyCblqUAwibiFiDiBCwfKWSI X/sWxpITWeHuPmSwkgs89RF2szbuNFPYVJTqzzVwvpE4xLpekCcxJNFJTuRUHwfr8yLqU4 OUt7th3t047ypVpbLd0/jPRV0xTIcSk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-176-Jp2i2IejOYKjziqHxtVHZQ-1; Fri, 03 Feb 2023 15:13:18 -0500 X-MC-Unique: Jp2i2IejOYKjziqHxtVHZQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 33DFD185A7A4 for ; Fri, 3 Feb 2023 20:13:18 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E85A92166B34; Fri, 3 Feb 2023 20:13:17 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 313KDFJa1415104 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 3 Feb 2023 21:13:16 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 313KDFwn1415103; Fri, 3 Feb 2023 21:13:15 +0100 Resent-From: Jakub Jelinek Resent-Date: Fri, 3 Feb 2023 21:13:15 +0100 Resent-Message-ID: Resent-To: Aldy Hernandez , GCC patches Date: Fri, 3 Feb 2023 17:25:58 +0100 From: Jakub Jelinek To: Andrew MacLeod Cc: Aldy Hernandez , GCC patches Subject: Re: [PATCH] [PR tree-optimization/18639] Compare nonzero bits in irange with widest_int. Message-ID: Reply-To: Jakub Jelinek References: <20230203085043.157321-1-aldyh@redhat.com> <4fc527b8-c5e0-97a6-725f-8e86b7c1e494@redhat.com> MIME-Version: 1.0 In-Reply-To: <4fc527b8-c5e0-97a6-725f-8e86b7c1e494@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 03, 2023 at 11:23:28AM -0500, Andrew MacLeod wrote: > > On 2/3/23 04:16, Jakub Jelinek wrote: > > On Fri, Feb 03, 2023 at 09:50:43AM +0100, Aldy Hernandez wrote: > > > [PR tree-optimization/18639] Compare nonzero bits in irange with widest_int. > > 0 missing in the bug number in the subject line, though the current > > recommended formatting of the subject is I think: > > value-range: Compare nonzero bits in irange with widest_int [PR180639] > > PR 108639/tree-optimization > > > > Reversed component and number > > > > > --- a/gcc/value-range.cc > > > +++ b/gcc/value-range.cc > > > @@ -1259,7 +1259,10 @@ irange::legacy_equal_p (const irange &other) const > > > other.tree_lower_bound (0)) > > > && vrp_operand_equal_p (tree_upper_bound (0), > > > other.tree_upper_bound (0)) > > > - && get_nonzero_bits () == other.get_nonzero_bits ()); > > > + && (widest_int::from (get_nonzero_bits (), > > > + TYPE_SIGN (type ())) > > > + == widest_int::from (other.get_nonzero_bits (), > > > + TYPE_SIGN (other.type ())))); > > > } > > > bool > > > @@ -1294,7 +1297,11 @@ irange::operator== (const irange &other) const > > > || !operand_equal_p (ub, ub_other, 0)) > > > return false; > > > } > > > - return get_nonzero_bits () == other.get_nonzero_bits (); > > > + widest_int nz1 = widest_int::from (get_nonzero_bits (), > > > + TYPE_SIGN (type ())); > > > + widest_int nz2 = widest_int::from (other.get_nonzero_bits (), > > > + TYPE_SIGN (other.type ())); > > > + return nz1 == nz2; > > > } > > While the above avoids the ICE (and would be certainly correct for > > the bounds, depending on the sign of their type sign or zero extended > > to widest int), but is the above what we want for non-zero bits > > to be considered equal? The wide_ints (which ought to have precision > > of the corresponding type) don't represent normal numbers but bitmasks, > > 0 - this bit is known to be zero, 1 - nothing is known about this bit). > > So, if there are different precisions and the narrower value has 0 > > in the MSB of the bitmask (so MSB is known to be zero), the above requires > > for equality that in the other range all upper bits are known to be zero > > too for both signed and unsigned. That is ok. Similarly for MSB set > > if TYPE_SIGN of the narrower is unsigned, the MSB value is unknown, but we > > require on the wider to have all the upper bits cleared. But for signed > > narrower type with MSB set, i.e. it is unknown if it is positive or > > negative, the above requires that all the above bits are unknown too. > > And that is the case I'm not sure about, whether in that case the > > upper bits of the wider wide_int should be checked at all. > > Though, perhaps from the POV of nonzero bits derived from the sign-extended > > values in the ranges sign bit copies (so all above bits 1) is what one would > > get, so maybe it is ok. Just food for thought. > > > if the bits match exactly along with everything else, then we can be sure > the ranges are truly equal.  If for some reason the numbers are all the same > but the non-zero bits don't compare equal,  then I can't think of what harm > it could cause to compare unequal..  Worst case is we dont perform some > optimization in this extremely rare scenario of differing precisions.  And > in fact they could actually be unequal... > > So I suspect this is fine... Ok then. Jakub