From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2136) id BFC523884505; Fri, 11 Nov 2022 13:53:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BFC523884505 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668174829; bh=Xquarkm1/ptXjjetKT/jPXxrPim/UoY/xuIhVQDi+hI=; h=From:To:Subject:Date:From; b=QvSBqbLYAaSbd5WyS8Kxta7MgaPU1qFTHYWXYVx4rY4xtrzmXSdGA+jUPgA+T9WK2 35Ee8eG1GBpEKlKPRKR61XPCNyxOeCicRzSDLdvVFUn0qRjx1d6Q8CXbLMa0/lijfd m2ggyVUGW7j5auNXMCWLO8ziRYQmCMSapFp66Enc= 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-3901] [range-ops] Update known bitmasks using CCP for all operators. X-Act-Checkin: gcc X-Git-Author: Aldy Hernandez X-Git-Refname: refs/heads/master X-Git-Oldrev: b3e8dc87b79a0c887e16553e975aa54f694f1de1 X-Git-Newrev: c16c40808331a02947b1ad962e85e1b40e30a707 Message-Id: <20221111135349.BFC523884505@sourceware.org> Date: Fri, 11 Nov 2022 13:53:49 +0000 (GMT) List-Id: https://gcc.gnu.org/g:c16c40808331a02947b1ad962e85e1b40e30a707 commit r13-3901-gc16c40808331a02947b1ad962e85e1b40e30a707 Author: Aldy Hernandez Date: Thu Nov 10 11:24:48 2022 +0100 [range-ops] Update known bitmasks using CCP for all operators. 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. Diff: --- 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;