From patchwork Tue Sep 12 15:25:12 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 1833099 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=CNIGoeW5; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RlSB25QV0z1yhZ for ; Wed, 13 Sep 2023 01:27:06 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BBDC8382DC44 for ; Tue, 12 Sep 2023 15:27:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBDC8382DC44 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694532424; bh=LeYyR2ZrUwKKa8ygOny3vB4VWcKHAlvHBpS8GDIKCnk=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=CNIGoeW5oL29hOwfvR6puaqkbVC7HjWmUVfWv1Xr43QneeDofkze6Jx5V9UO2nD+X OixGstdO5GmxJegI3q6QuAJsi87WBc4OaiuC4IdytL3VWOT0p8lcmch+iKPw2kEEkI dA0EI+GOfEN8VqJs2ieliPlJ1ndi4y999goIvrTU= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 3C8AD3853570 for ; Tue, 12 Sep 2023 15:25:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C8AD3853570 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 21BC81007; Tue, 12 Sep 2023 08:26:17 -0700 (PDT) Received: from e121540-lin.manchester.arm.com (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 782D43F738; Tue, 12 Sep 2023 08:25:39 -0700 (PDT) To: gcc-patches@gcc.gnu.org Cc: Richard Sandiford Subject: [PATCH 02/19] aarch64: Avoid a use of callee_offset Date: Tue, 12 Sep 2023 16:25:12 +0100 Message-Id: <20230912152529.3322336-3-richard.sandiford@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230912152529.3322336-1-richard.sandiford@arm.com> References: <20230912152529.3322336-1-richard.sandiford@arm.com> MIME-Version: 1.0 X-Spam-Status: No, score=-25.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Richard Sandiford via Gcc-patches From: Richard Sandiford Reply-To: Richard Sandiford Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" When we emit the frame chain, i.e. when we reach Here in this statement of aarch64_expand_prologue: if (emit_frame_chain) { // Here ... } the stack is in one of two states: - We've allocated up to the frame chain, but no more. - We've allocated the whole frame, and the frame chain is within easy reach of the new SP. The offset of the frame chain from the current SP is available in aarch64_frame as callee_offset. It is also available as the chain_offset local variable, where the latter is calculated from other data. (However, chain_offset is not always equal to callee_offset when !emit_frame_chain, so chain_offset isn't redundant.) In c600df9a4060da3c6121ff4d0b93f179eafd69d1 I switched to using chain_offset for the initialisation of the hard frame pointer: aarch64_add_offset (Pmode, hard_frame_pointer_rtx, - stack_pointer_rtx, callee_offset, + stack_pointer_rtx, chain_offset, tmp1_rtx, tmp0_rtx, frame_pointer_needed); But the later REG_CFA_ADJUST_CFA handling still used callee_offset. I think the difference is harmless, but it's more logical for the CFA note to be in sync, and it's more convenient for later patches if it uses chain_offset. gcc/ * config/aarch64/aarch64.cc (aarch64_expand_prologue): Use chain_offset rather than callee_offset. --- gcc/config/aarch64/aarch64.cc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index b91f77d7b1f..9fb94623693 100644 --- a/gcc/config/aarch64/aarch64.cc +++ b/gcc/config/aarch64/aarch64.cc @@ -10034,7 +10034,6 @@ aarch64_expand_prologue (void) poly_int64 initial_adjust = frame.initial_adjust; HOST_WIDE_INT callee_adjust = frame.callee_adjust; poly_int64 final_adjust = frame.final_adjust; - poly_int64 callee_offset = frame.callee_offset; poly_int64 sve_callee_adjust = frame.sve_callee_adjust; poly_int64 below_hard_fp_saved_regs_size = frame.below_hard_fp_saved_regs_size; @@ -10147,8 +10146,7 @@ aarch64_expand_prologue (void) implicit. */ if (!find_reg_note (insn, REG_CFA_ADJUST_CFA, NULL_RTX)) { - rtx src = plus_constant (Pmode, stack_pointer_rtx, - callee_offset); + rtx src = plus_constant (Pmode, stack_pointer_rtx, chain_offset); add_reg_note (insn, REG_CFA_ADJUST_CFA, gen_rtx_SET (hard_frame_pointer_rtx, src)); }