From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 0B8333857C57 for ; Tue, 4 Aug 2020 09:45:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0B8333857C57 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-241-IY9BKgmhMyWSaCjotq1D_Q-1; Tue, 04 Aug 2020 05:45:17 -0400 X-MC-Unique: IY9BKgmhMyWSaCjotq1D_Q-1 Received: by mail-wr1-f69.google.com with SMTP id t3so11409758wrr.5 for ; Tue, 04 Aug 2020 02:45:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=su5BAmFSS3q2J1DjxPu282W9O4thoNs8MzKirL5a+xQ=; b=LSaJo/OsxgysJ4qM6+iAnYJZJRZcce3VW1oeilfHH5VPXMyQUAPgmOkz20NM3TOGLU 4wQF7miXW2G/Idbr+aLYAx61rObxThCMgmnFJu+no+7oixSRyg0dS0sln56t/EfV2jUk P7LEwPDka4RV21vmjfhUpnaIrfmHp9llg0kZ69K+FNliG1yhhqjEDJyKlfn2O7D+NsfP Vfc64NJZub8Ah7u2XnMMhWHq0EpBknyVMZjbHHVqQ03JU4KMMHYeZOWKIEvWbaiBw2Y2 9HhB49hYDuJhKEsmN7DrQ/WUwChnt0wbDwCXMeI5ktrBIR57gVv6ego37ey3u/j+uky+ wvjw== X-Gm-Message-State: AOAM5306XEWrR7jm3zYX+HkOYDW7bDruG3MCuSqD9lOv8fPenPCcN4Qb oskDilXCmt4L2pjrqdXeP7Q5PLXGU+1XnePi4M7wUfHGfo3ZwfxFxii6rPHzlAeWXdMTOvDok56 Tml1kj5QyLt+8SFR0yg== X-Received: by 2002:adf:de09:: with SMTP id b9mr18975361wrm.409.1596534315428; Tue, 04 Aug 2020 02:45:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyPtpzKWJQWo/r1GwmrlxjYKBc+foiPvvOXhnR8osJt/UU0OD1KtyYFzW6DP8euL1oYONnKg== X-Received: by 2002:adf:de09:: with SMTP id b9mr18975345wrm.409.1596534315203; Tue, 04 Aug 2020 02:45:15 -0700 (PDT) Received: from abulafia.quesejoda.com ([95.169.235.146]) by smtp.gmail.com with ESMTPSA id g126sm3777706wme.16.2020.08.04.02.45.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2020 02:45:14 -0700 (PDT) Subject: Re: [PUSHED 4/8] Adjust op_with_boolean_value_range_p for irange API. To: Richard Biener Cc: GCC Patches References: <20200804063441.517123-1-aldyh@redhat.com> <20200804063441.517123-5-aldyh@redhat.com> From: Aldy Hernandez Message-ID: Date: Tue, 4 Aug 2020 11:45:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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-List-Received-Date: Tue, 04 Aug 2020 09:45:20 -0000 On 8/4/20 8:55 AM, Richard Biener wrote: > On Tue, Aug 4, 2020 at 8:39 AM Aldy Hernandez via Gcc-patches > wrote: >> >> It seems to me that we should also check for [0,0] and [1,1] in the >> range, but I am leaving things as is to avoid functional changes. >> >> gcc/ChangeLog: >> >> * vr-values.c (simplify_using_ranges::op_with_boolean_value_range_p): Adjust >> for irange API. >> --- >> gcc/vr-values.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/gcc/vr-values.c b/gcc/vr-values.c >> index 609375c072e..1190fa96453 100644 >> --- a/gcc/vr-values.c >> +++ b/gcc/vr-values.c >> @@ -448,10 +448,11 @@ simplify_using_ranges::op_with_boolean_value_range_p (tree op) >> if (TREE_CODE (op) != SSA_NAME) >> return false; >> >> + /* ?? Errr, this should probably check for [0,0] and [1,1] as well >> + as [0,1]. */ >> const value_range *vr = get_value_range (op); >> - return (vr->kind () == VR_RANGE >> - && integer_zerop (vr->min ()) >> - && integer_onep (vr->max ())); >> + return *vr == value_range (build_zero_cst (TREE_TYPE (op)), >> + build_one_cst (TREE_TYPE (op))); > > This now builds trees in a predicate which is highly dubious. Isn't > there a better (cheaper) primitive to build a [0, 1] range to compare against? > I guess from what I read it will also allocate memory for the range entry? Both 0 and 1 are cached for all integer types. We are also caching 1 and MAX for pointers per the irange patchset, so this shouldn't be a performance issue. Also, we do the same thing for irange::nonzero_p(), which is used a lot more often (and probably on critical paths), and per our benchmarks we didn't find it to take any significant time: tree zero = build_zero_cst (type ()); return *this == int_range<1> (zero, zero, VR_ANTI_RANGE); However, I suppose we could implement it with something like: return vr->num_pairs() == 1 && vr->lower_bound () == 0 && vr->upper_bound () == 1 but that's hardly any faster, especially since num_pairs() is non-trivial for the value_range legacy code. I just don't think it's worth it. Aldy