public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "wilson at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/94173] [RISCV] Superfluous stackpointer manipulation Date: Mon, 16 Mar 2020 22:21:22 +0000 [thread overview] Message-ID: <bug-94173-4-qsEAs4w2ZQ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-94173-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94173 Jim Wilson <wilson at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> --- struct Pair has size 8 and align 4, and we have no unaligned load/store support, so we are not able to allocate the temporary local variable to a register. It must be allocated a stack slot. The RTL optimizer is able to figure out that the stack stores and loads don't alias anything and hence are not necessary and optimizes them away. However, we don't have any support to unallocate a stack slot after it has already been allocated, so we end up with the unnecessary stack pointer increment and decrement. In a degenerate case like this, where there are no longer any stack loads/stores, we may be able to notice that and get rid of the stack pointer manipulation. But in a more complicated case where there are multiple stack slots, and references to all but one is optimized away, then we would still need the stack pointer change, though we would just be wasting stack space in this case with larger decrements/increments than needed. If you change the type to truct Pair { char *s; char *t; } __attribute__ ((aligned(8))); then you get the result you want. That isn't a practical solution, but it demonstrates that this is a size/alignment/strict-alignment problem. This is more of a middle end problem than a RISC-V backend problem. It should be possible to reproduce on any target with similar strict alignment constraints, and similar calling conventions that allow returning the structure in registers, though I don't know if there are any offhand.
next prev parent reply other threads:[~2020-03-16 22:21 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-14 9:04 [Bug target/94173] New: " gcc at gms dot tf 2020-03-16 22:21 ` wilson at gcc dot gnu.org [this message] 2020-03-16 22:21 ` [Bug target/94173] " wilson at gcc dot gnu.org 2020-03-16 22:27 ` andrew at sifive dot com 2020-03-16 22:34 ` wilson 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-94173-4-qsEAs4w2ZQ@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).