public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jlaw@tachyum.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Aligning stack offsets for spills
Date: Mon, 7 Jun 2021 13:00:21 -0600	[thread overview]
Message-ID: <98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com> (raw)


So, as many of you know I left Red Hat a while ago and joined Tachyum.  
We're building a new processor and we've come across an issue where I 
think we need upstream discussion.

I can't divulge many of the details right now, but one of the quirks of 
our architecture is that reg+d addressing modes for our vector 
loads/stores require the displacement to be aligned.  This is an 
artifact of how these instructions are encoded.

Obviously we can emit a load of the address into a register when the 
displacement isn't aligned.  From a correctness point that works 
perfectly.  Unfortunately, it's a significant performance hit on some 
standard benchmarks (spec) where we have a great number of spills of 
vector objects into the stack at unaligned offsets in the hot parts of 
the code.


We've considered 3 possible approaches to solve this problem.

1. When the displacement isn't properly aligned, allocate more space in 
assign_stack_local so that we can make the offset aligned.  The downside 
is this potentially burns a lot of stack space, but in practice the cost 
was minimal (16 bytes in a 9k frame)  From a performance standpoint this 
works perfectly.

2. Abuse the register elimination code to create a second pointer into 
the stack.  Spills would start as <virtual> + offset, then either get 
eliminated to sp+offset' when the offset is aligned or gpr+offset'' when 
the offset wasn't properly aligned. We started a bit down this path, but 
with #1 working so well, we didn't get this approach to proof-of-concept.

3. Hack up the post-reload optimizers to fix things up as best as we 
can.  This may still be advantageous, but again with #1 working so well, 
we didn't explore this in any significant way.  We may still look at 
this at some point in other contexts.



Here's what we're playing with.  Obviously we'd need a target hook to 
drive this behavior.  I was thinking that we'd pass in any slot offset 
alignment requirements (from the target hook) to assign_stack_local and 
that would bubble down to this point in try_fit_stack_local:

diff --git a/gcc/function.c b/gcc/function.c
index d616f5f64f4..7f441b87a63 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -307,6 +307,14 @@ try_fit_stack_local (poly_int64 start, poly_int64 
length,
    frame_off = targetm.starting_frame_offset () % frame_alignment;
    frame_phase = frame_off ? frame_alignment - frame_off : 0;

+  if (known_eq (size, 64) && alignment < 64)
+    alignment = 64;
+
    /* Round the frame offset to the specified alignment.  */

    if (FRAME_GROWS_DOWNWARD)

Thoughts?

Jeff

             reply	other threads:[~2021-06-07 19:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 19:00 Jeff Law [this message]
2021-06-08  6:56 ` Richard Biener
2021-06-08 15:00   ` Jeff Law
2021-06-08 14:08 ` Michael Matz
2021-06-08 14:47   ` Jeff Law
2021-06-08 14:55     ` Jakub Jelinek
2021-06-08 15:06       ` H.J. Lu
2021-06-08 15:18         ` Jeff Law
2021-06-08 15:56           ` Michael Matz
2021-06-10 22:49       ` Jeff Law
2021-06-10 19:28 ` Peter Bergner
2021-06-10 21:34   ` Segher Boessenkool

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=98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com \
    --to=jlaw@tachyum.com \
    --cc=gcc-patches@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).