From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com 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) From: Richard Sandiford 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 Content-Transfer-Encoding: 8bit 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 List-Id: 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)); } -- 2.25.1