public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Richard Sandiford <rsandifo@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/vendors/ARM/heads/CVE-2023-4039/gcc-10)] aarch64: Add bytes_below_hard_fp to frame info Date: Tue, 12 Sep 2023 15:24:50 +0000 (GMT) [thread overview] Message-ID: <20230912152450.7D81E3853D02@sourceware.org> (raw) https://gcc.gnu.org/g:a519149de34facf645064c1ea5748aeb7d72aca4 commit a519149de34facf645064c1ea5748aeb7d72aca4 Author: Richard Sandiford <richard.sandiford@arm.com> Date: Tue Jun 27 11:17:33 2023 +0100 aarch64: Add bytes_below_hard_fp to frame info Following on from the previous bytes_below_saved_regs patch, this one records the number of bytes that are below the hard frame pointer. This eventually replaces below_hard_fp_saved_regs_size. If a frame pointer is not needed, the epilogue adds final_adjust to the stack pointer before restoring registers: aarch64_add_sp (tmp1_rtx, tmp0_rtx, final_adjust, true); Therefore, if the epilogue needs to restore the stack pointer from the hard frame pointer, the directly corresponding offset is: -bytes_below_hard_fp + final_adjust i.e. go from the hard frame pointer to the bottom of the frame, then add the same amount as if we were using the stack pointer from the outset. gcc/ * config/aarch64/aarch64.h (aarch64_frame::bytes_below_hard_fp): New field. * config/aarch64/aarch64.c (aarch64_layout_frame): Initialize it. (aarch64_expand_epilogue): Use it instead of below_hard_fp_saved_regs_size. Diff: --- gcc/config/aarch64/aarch64.c | 6 +++--- gcc/config/aarch64/aarch64.h | 5 +++++ 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 6109518189fb..2652515b3615 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -6954,6 +6954,7 @@ aarch64_layout_frame (void) of the callee save area. */ bool saves_below_hard_fp_p = maybe_ne (offset, 0); frame.below_hard_fp_saved_regs_size = offset; + frame.bytes_below_hard_fp = offset + frame.bytes_below_saved_regs; if (frame.emit_frame_chain) { /* FP and LR are placed in the linkage record. */ @@ -8481,8 +8482,7 @@ aarch64_expand_epilogue (bool for_sibcall) 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; + poly_int64 bytes_below_hard_fp = frame.bytes_below_hard_fp; unsigned reg1 = frame.wb_candidate1; unsigned reg2 = frame.wb_candidate2; rtx cfi_ops = NULL; @@ -8538,7 +8538,7 @@ aarch64_expand_epilogue (bool for_sibcall) is restored on the instruction doing the writeback. */ aarch64_add_offset (Pmode, stack_pointer_rtx, hard_frame_pointer_rtx, - -callee_offset - below_hard_fp_saved_regs_size, + -bytes_below_hard_fp + final_adjust, tmp1_rtx, tmp0_rtx, callee_adjust == 0); else /* The case where we need to re-use the register here is very rare, so diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h index 083ffbfbc530..a4cbc678cef3 100644 --- a/gcc/config/aarch64/aarch64.h +++ b/gcc/config/aarch64/aarch64.h @@ -829,6 +829,11 @@ struct GTY (()) aarch64_frame are saved below the hard frame pointer. */ poly_int64 below_hard_fp_saved_regs_size; + /* The number of bytes between the bottom of the static frame (the bottom + of the outgoing arguments) and the hard frame pointer. This value is + always a multiple of STACK_BOUNDARY. */ + poly_int64 bytes_below_hard_fp; + /* Offset from the base of the frame (incomming SP) to the top of the locals area. This value is always a multiple of STACK_BOUNDARY. */
reply other threads:[~2023-09-12 15:24 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230912152450.7D81E3853D02@sourceware.org \ --to=rsandifo@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).