From patchwork Tue May 11 08:56:31 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julian Brown X-Patchwork-Id: 1476980 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@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 4FfWyJ1H5xz9sjJ for ; Tue, 11 May 2021 18:57:12 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 55A6A3886C55; Tue, 11 May 2021 08:57:02 +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 1737F3857801; Tue, 11 May 2021 08:56:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1737F3857801 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Julian_Brown@mentor.com IronPort-SDR: 81zAQP3hCe89jzFacizRL69QEse/R1hs36sfZLx4y+RcqUDzPGOPj6niPPIkM8MHGZKn+550Sl i8Ze+dabOQmlTU8fhBlbrI4mX6EGDGGeiyp3MB9v6GI37GrSsR6opBdB5MRKtJmcnXlDQrYH/y HhHSleAKtGZdGlHVMRQYOT1rIDg6H6MYsagv+wEY2BmcaXuNN6XJXPM9bGPnB4s78iqhsE/u7l ejoCsOIP4Uww7j6DidQVTlibVBjVlImv7WCkcJmHaYZ36Zdn3Ecse4XNxV5H3kXuykxVedUG7e zLI= X-IronPort-AV: E=Sophos;i="5.82,290,1613462400"; d="scan'208";a="61053240" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 11 May 2021 00:56:59 -0800 IronPort-SDR: VFFXf3ROJCF2ENJ15yXmSDvMGYQu1UpHhEdrKOue0waJak9iN/8tcws41V5158Y21qw5m/n8Jj mOhITo+Px9AgFyvmoWV4kM7om7VVPTlklqQmArGkr4kmfXbV3AH3HgvMeqgyXb3y32vIug9waa DZXwrekvc+zZRijt29qy9puEArsHcvi0fNFt3SIaZNYnnN2C1/9GSQAe8qCmy1W76DBct9e2dB wBfVCheRsfFqlGwqFOfsi3XfubpfCG2N2gF3H+hxOeIkb2TgX0MVD129Zv/THtJ0v5cmydsDGk /jY= From: Julian Brown To: Subject: [PATCH 1/7] [og10] Unify ARRAY_REF/INDIRECT_REF stripping code in extract_base_bit_offset Date: Tue, 11 May 2021 01:56:31 -0700 Message-ID: <23c6b39543ca5a94d59682cc66e136109da086ea.1620721888.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-09.mgc.mentorg.com (139.181.222.9) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_NONE, 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@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-05-11 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 ba071e8ae68..b36b961bf26 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -8340,31 +8340,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);