From patchwork Fri Nov 11 13:53:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 60412 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2EAD23889E17 for ; Fri, 11 Nov 2022 13:53:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2EAD23889E17 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668174839; bh=sTOv5qVodcgsfN7G3p/V8MQmFvOuBRVAcQh8zxPARo0=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=b2ueDJC2R17JUuXCxA66IjSpHC/utRi6ibMJREqp6rQm1j2nynMiUByqI8bcgDPz2 /O+m8Q/g2NHubs791A1lU122O9h/sCDqZjZhGJN0dg02XecUxv4Z7qMm+z9avR8a92 Q27sgSErhheCSsbWwc5q5K7S9pyr0FMh8E5qbQgA= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 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 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 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Aldy Hernandez via Gcc-patches From: Aldy Hernandez Reply-To: Aldy Hernandez Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" 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;