From patchwork Wed Jun 2 10:45:24 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julian Brown X-Patchwork-Id: 1486580 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4Fw5MS6GHsz9sCD for ; Wed, 2 Jun 2021 20:47:32 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E7C293959E72 for ; Wed, 2 Jun 2021 10:47:30 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id C8136387088D; Wed, 2 Jun 2021 10:45:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C8136387088D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 6+gw0g+ui0VbA3RZjWZeRAdbv08QxYEuiVCEkX/Ax1tTsPmZV0hJFe7Yi27GdSJI8h5ZOg4tB5 zvO+0l5ko9tBNMCCGwe1kTJJ3ZHi+n4/fORtVp+I2xZGGTSSZLoaUiahWvczRMO2RjVsvlSPIm Peuj+DStoq8PmZkNlgDf6Muo+zNqpUQOG6DFy971JXXV4M2cmUwIxZQ+Cmj6ld1r0Er9APtDwt N8KkgBGoIr2IGGBaAo6A+h/txZE+qS+5EG99NaFq/4+HMdWK8frkTm4Dz8d9grkBZUw8h0Aofj oEs= X-IronPort-AV: E=Sophos;i="5.83,242,1616486400"; d="scan'208";a="61902747" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 02 Jun 2021 02:45:44 -0800 IronPort-SDR: PtxNcC7ydacXF/mXprJ1ODJD0vZZIHYX0NtLBhzcp9iMbUyycfXSJ9HnXA+DSF/zdbdr19h5IA 19c9ycM25MVzpladUP6h8FohM/n9CjYXuTRbcXBvfDtK42YfvN6+AQGC6bbD1J608BFYS2p+xc 4e/KlAYbCai5KAAC/ZzXebXiCuAREk6MWDhgT3NONFHcjrZ+8LRV/2brE0PKeqHaFh4pcZWRYm XhIQ73qHQaFKe72VoGO7GLnwuQ3iOaSsA820Rky1VRiXECbwyYmQJbH1M6s0htfp5izR+gOU2b 8I0= From: Julian Brown To: Subject: [PATCH 2/4] [og11] Unify ARRAY_REF/INDIRECT_REF stripping code in extract_base_bit_offset Date: Wed, 2 Jun 2021 03:45:24 -0700 Message-ID: <309548a704fdfbf6b2786d0eac659d4a493af65f.1622630252.git.julian@codesourcery.com> X-Mailer: git-send-email 2.29.2 In-Reply-To: References: MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, 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: , Cc: Jakub Jelinek , Tobias Burnus , fortran@gcc.gnu.org, Thomas Schwinge Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" For historical reasons, it seems that extract_base_bit_offset unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF nodes from component accesses. I verified that the two ways of performing the operation gave the same results across the whole testsuite (and several additional benchmarks). The code was like this since an earlier "mechanical" refactoring by me, first posted here: https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html It was never clear to me if there was an important semantic difference between the two ways of stripping the base before calling get_inner_reference, but it appears that there is not, so one can go away. 2021-06-02 Julian Brown gcc/ * gimplify.c (extract_base_bit_offset): Unify ARRAY_REF/INDIRECT_REF stripping code in first call/subsequent call cases. --- gcc/gimplify.c | 32 +++++++++++--------------------- 1 file changed, 11 insertions(+), 21 deletions(-) diff --git a/gcc/gimplify.c b/gcc/gimplify.c index a38cd502aa5..255a2a648c1 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -8527,31 +8527,21 @@ extract_base_bit_offset (tree base, tree *base_ref, poly_int64 *bitposp, poly_offset_int poffset; if (base_ref) - { - *base_ref = NULL_TREE; - - while (TREE_CODE (base) == ARRAY_REF) - base = TREE_OPERAND (base, 0); + *base_ref = NULL_TREE; - if (TREE_CODE (base) == INDIRECT_REF) - base = TREE_OPERAND (base, 0); - } - else + if (TREE_CODE (base) == ARRAY_REF) { - if (TREE_CODE (base) == ARRAY_REF) - { - while (TREE_CODE (base) == ARRAY_REF) - base = TREE_OPERAND (base, 0); - if (TREE_CODE (base) != COMPONENT_REF - || TREE_CODE (TREE_TYPE (base)) != ARRAY_TYPE) - return NULL_TREE; - } - else if (TREE_CODE (base) == INDIRECT_REF - && TREE_CODE (TREE_OPERAND (base, 0)) == COMPONENT_REF - && (TREE_CODE (TREE_TYPE (TREE_OPERAND (base, 0))) - == REFERENCE_TYPE)) + while (TREE_CODE (base) == ARRAY_REF) base = TREE_OPERAND (base, 0); + if (TREE_CODE (base) != COMPONENT_REF + || TREE_CODE (TREE_TYPE (base)) != ARRAY_TYPE) + return NULL_TREE; } + else if (TREE_CODE (base) == INDIRECT_REF + && TREE_CODE (TREE_OPERAND (base, 0)) == COMPONENT_REF + && (TREE_CODE (TREE_TYPE (TREE_OPERAND (base, 0))) + == REFERENCE_TYPE)) + base = TREE_OPERAND (base, 0); base = get_inner_reference (base, &bitsize, &bitpos, &offset, &mode, &unsignedp, &reversep, &volatilep);