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.129.124]) by sourceware.org (Postfix) with ESMTPS id 4ACD03858D38 for ; Fri, 11 Nov 2022 13:53:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4ACD03858D38 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=1668174807; h=from:from: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: in-reply-to:in-reply-to:references:references; bh=sTOv5qVodcgsfN7G3p/V8MQmFvOuBRVAcQh8zxPARo0=; b=EfdVrKcEOQdv+eRWFqJL+9wtiRVRXvIxFPaVRxLjteVh+D3Yco6/OJAfU6IRlRSzQYQv9F xlSj0iLtHvqkGPj9XR4HDnOvG8xpJI92UnyalcmgKWbUgkUXy9jbadmMBTSM+l2fuE58+0 iOi98NoC11efdXZ9fAsGx9PiI1GG8qw= 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-653-1Ma4NJSWPaadKrmIVRKxfg-1; Fri, 11 Nov 2022 08:53:26 -0500 X-MC-Unique: 1Ma4NJSWPaadKrmIVRKxfg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9642285A5B6 for ; Fri, 11 Nov 2022 13:53:26 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.192.220]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4D834492B0A; Fri, 11 Nov 2022 13:53:26 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.17.1/8.17.1) with ESMTPS id 2ABDrOvX235455 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 11 Nov 2022 14:53:24 +0100 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 2ABDrOBw235454; Fri, 11 Nov 2022 14:53:24 +0100 From: Aldy Hernandez To: GCC patches Cc: Andrew MacLeod , Aldy Hernandez Subject: [COMMITTED] [range-ops] Update known bitmasks using CCP for all operators. Date: Fri, 11 Nov 2022 14:53:16 +0100 Message-Id: <20221111135318.235387-3-aldyh@redhat.com> In-Reply-To: <20221111135318.235387-1-aldyh@redhat.com> References: <20221111135318.235387-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: Use bit-CCP to calculate bitmasks for all integer operators, instead of the half-assed job we were doing with just a handful of operators. This sets us up nicely for tracking known-one bitmasks in the next release, as all we'll have to do is just store them in the irange. All in all, this series of patches incur a 1.9% penalty to VRP, with no measurable difference in overall compile time. The reason is three-fold: (a) There's double dispatch going on. First, the dispatch for the range-ops virtuals, and now the switch in bit_value_binop. (b) The maybe nonzero mask is stored as a tree and there is an endless back and forth with wide-ints. This will be a non-issue next release, when we convert irange to wide-ints. (c) New functionality has a cost. We were handling 2 cases (plus casts). Now we handle 20. I can play around with moving the bit_value_binop cases into inlined methods in the different range-op entries, and see if that improves anything, but I doubt (a) buys us that much. Certainly something that can be done in stage3 if it's measurable in any significant way. p.s It would be nice in the future to teach the op[12]_range methods about the masks. gcc/ChangeLog: * range-op.cc (range_operator::fold_range): Call update_known_bitmask. (operator_bitwise_and::fold_range): Avoid setting nonzero bits when range is undefined. --- gcc/range-op.cc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gcc/range-op.cc b/gcc/range-op.cc index 00a736e983d..9eec46441a3 100644 --- a/gcc/range-op.cc +++ b/gcc/range-op.cc @@ -245,6 +245,7 @@ range_operator::fold_range (irange &r, tree type, wi_fold_in_parts (r, type, lh.lower_bound (), lh.upper_bound (), rh.lower_bound (), rh.upper_bound ()); op1_op2_relation_effect (r, type, lh, rh, rel); + update_known_bitmask (r, m_code, lh, rh); return true; } @@ -262,10 +263,12 @@ range_operator::fold_range (irange &r, tree type, if (r.varying_p ()) { op1_op2_relation_effect (r, type, lh, rh, rel); + update_known_bitmask (r, m_code, lh, rh); return true; } } op1_op2_relation_effect (r, type, lh, rh, rel); + update_known_bitmask (r, m_code, lh, rh); return true; } @@ -2873,7 +2876,7 @@ operator_bitwise_and::fold_range (irange &r, tree type, { if (range_operator::fold_range (r, type, lh, rh)) { - if (!lh.undefined_p () && !rh.undefined_p ()) + if (!r.undefined_p () && !lh.undefined_p () && !rh.undefined_p ()) r.set_nonzero_bits (wi::bit_and (lh.get_nonzero_bits (), rh.get_nonzero_bits ())); return true; -- 2.38.1