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.

  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: link
Be 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).