public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM) Date: Thu, 04 Jun 2020 12:41:48 +0000 [thread overview] Message-ID: <bug-69008-4-LiQdtvFoET@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-69008-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69008 Philip Blundell <pb at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pb at gcc dot gnu.org --- Comment #8 from Philip Blundell <pb at gcc dot gnu.org> --- There seem to be a few different things going on here. With the current state of master, I no longer get the redundant ldm using the testcase from comment #7. But the store is still there: .LFB1: @ args = 0, pretend = 0, frame = 8 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. sub sp, sp, #8 add r3, sp, #8 stmdb r3, {r0, r1} sub r3, r1, #1 add sp, sp, #8 add r0, r0, r3 @ sp needed bx lr A brief inspection of the rtl suggests that the way that we wrap multiple stores in a PARALLEL might be preventing DSE from deleting the dead store. If I hack arm.md to disable the define_expand "store_multiple" then the store goes away: .LFB1: @ args = 0, pretend = 0, frame = 8 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. sub sp, sp, #8 sub r1, r1, #1 add sp, sp, #8 add r0, r0, r1 @ sp needed bx lr But we're still left with the useless stack pointer manipulation. As Andrew said in comment #4, what seems to have happened here is that we reserve a stack slot for the incoming args because they are BLKmode and, even though all the memory accesses end up being deleted, the space in the stack frame is still reserved and sp gets bumped to accommodate it. The memory references to the stack frame have been eliminated before the prologue and epilogue are generated so presumably it wouldn't be impossible to detect that the frame is no longer actually needed at this point. But I don't know how hard this would be to do in the general case.
next prev parent reply other threads:[~2020-06-04 12:41 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-69008-4@http.gcc.gnu.org/bugzilla/> 2020-03-21 22:36 ` david.forgeas at gmail dot com 2020-06-04 12:41 ` pb at gcc dot gnu.org [this message] 2021-05-04 12:31 ` rguenth at gcc dot gnu.org
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=bug-69008-4-LiQdtvFoET@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).