From patchwork Mon Nov 8 15:06:00 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 47214 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 C48353858406 for ; Mon, 8 Nov 2021 15:06:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C48353858406 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1636384000; bh=Qtc9nS5TLn4t0+jis+f1infH2f1bTs3cBIExgE3gH64=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=pk/HT4RRNbn4UpC1aH+oD+MmxtOUcrgUgdi+ojFcSKHyX4rz+VAu/AUvjhOihEEci sZnESkE66dJwGv529rZln0AtuPqlYLrptf5vDfQ7bJSBBiT8fXiyDmyula3oEgbMZ+ CWK9e2mWeLBB5UC927lXFxCy3bXh/faY4Gocyft8= 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 10B093858415 for ; Mon, 8 Nov 2021 15:06:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 10B093858415 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-231-ECeyVasmMlWhEAzOelsujg-1; Mon, 08 Nov 2021 10:06:09 -0500 X-MC-Unique: ECeyVasmMlWhEAzOelsujg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ED6AC1023F55 for ; Mon, 8 Nov 2021 15:06:07 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.194.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4B77D60C17; Mon, 8 Nov 2021 15:06:07 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.16.1/8.15.2) with ESMTPS id 1A8F64pB262315 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 8 Nov 2021 16:06:04 +0100 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.16.1/8.16.1/Submit) id 1A8F63vr262314; Mon, 8 Nov 2021 16:06:03 +0100 To: GCC patches Subject: [COMMITTED] path solver: Avoid recalculating ranges already in the cache. Date: Mon, 8 Nov 2021 16:06:00 +0100 Message-Id: <20211108150600.262228-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-13.3 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_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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" The problem here is an ordering issue with a path that starts with 19->3: [local count: 916928331]: # value_20 = PHI # n_27 = PHI n_16 = n_27 + 4; value_17 = value_20 / 10000; if (value_20 > 42949672959999) goto ; [89.00%] else goto ; [11.00%] The problem here is that both value_17 and value_20 are in the set of imports we must pre-calculate. The value_17 name occurs first in the bitmap, so we try to resolve it first, which causes us to recursively solve the value_20 range. We do so correctly and put them both in the cache. However, when we try to solve value_20 from the bitmap, we ignore that it already has a cached entry and try to resolve the PHI with the wrong value of value_17: # value_20 = PHI The right thing to do is to avoid recalculating definitions already solved. Regstrapped and checked for # threads before and after on x86-64 Linux. gcc/ChangeLog: PR tree-optimization/103120 * gimple-range-path.cc (path_range_query::range_defined_in_block): gcc/testsuite/ChangeLog: * gcc.dg/pr103120.c: New test. --- gcc/gimple-range-path.cc | 3 +++ gcc/testsuite/gcc.dg/pr103120.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 gcc/testsuite/gcc.dg/pr103120.c diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc index 9175651e896..9d3fe89185e 100644 --- a/gcc/gimple-range-path.cc +++ b/gcc/gimple-range-path.cc @@ -300,6 +300,9 @@ path_range_query::range_defined_in_block (irange &r, tree name, basic_block bb) if (def_bb != bb) return false; + if (get_cache (r, name)) + return true; + if (gimple_code (def_stmt) == GIMPLE_PHI) ssa_range_in_phi (r, as_a (def_stmt)); else diff --git a/gcc/testsuite/gcc.dg/pr103120.c b/gcc/testsuite/gcc.dg/pr103120.c new file mode 100644 index 00000000000..b680a6c0fb0 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr103120.c @@ -0,0 +1,33 @@ +// { dg-do run } +// { dg-options "-O2" } + +#define radix 10 +__INT32_TYPE__ numDigits(__UINT64_TYPE__ value) +{ + __INT32_TYPE__ n = 1; + while (value > __UINT32_MAX__) + { + n += 4; + value /= radix * radix * radix * radix; + } + __UINT32_TYPE__ v = (__UINT32_TYPE__)value; + while (1) + { + if (v < radix) + return n; + if (v < radix * radix) + return n + 1; + if (v < radix * radix * radix) + return n + 2; + if (v < radix * radix * radix * radix) + return n + 3; + n += 4; + v /= radix * radix * radix * radix; + } +} + +int main() +{ + if (numDigits(__UINT64_MAX__) != 20) + __builtin_abort(); +}