public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Max Filippov <jcmvbkbc@gmail.com>
To: "Takayuki 'January June' Suwa" <jjsuwa_sys3175@yahoo.co.jp>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] xtensa: Optimize stack frame adjustment more
Date: Thu, 5 Jan 2023 22:26:53 -0800	[thread overview]
Message-ID: <CAMo8BfJkid+u8553c_76UUp52g8p8r8cbRWNAkLyLsjnPQkiXA@mail.gmail.com> (raw)
In-Reply-To: <bcef8fa4-88cf-f7d6-44b0-fe1efe089fd1@yahoo.co.jp>

On Thu, Jan 5, 2023 at 7:35 PM Takayuki 'January June' Suwa
<jjsuwa_sys3175@yahoo.co.jp> wrote:
> On second thought, it cannot be a good idea to split addition/subtraction to the stack pointer.
>
> > -    4aaf:      b0a192          movi    a9, 0x1b0
> > -    4ab2:      1f9a            add.n   a1, a15, a9
>
> > +    4aaf:      02df12          addmi   a1, a15, 0x200
> > +    4ab2:      b0c112          addi    a1, a1, -80
>
> Because the former is atomic, but the latter is not. (may be interrupted between the two add instructions)

Oh, right, there are two issues: one is interruption in the absence of
detailed stack tracking in the DWARF info, which can be fixed by emitting
a separate note for each a1 change, the other is interruption when
a1 is in the parent frame, which can be fixed by always moving a1
down first, e.g. with the following change:

diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 3b8a7bcda371..29cb91fa7de5 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -2539,7 +2539,10 @@ xtensa_split_imm_two_addends (HOST_WIDE_INT
imm, HOST_WIDE_INT v[2])

  if (xtensa_simm8 (v1) || xtensa_simm8x256 (v1))
    {
-      v[0] = v0, v[1] = v1;
+      if (v0 < 0)
+       v[0] = v0, v[1] = v1;
+      else
+       v[0] = v1, v[1] = v0;
      return true;
    }

Or both can be fixed by using a scratch register in the middle of the
addi/addmi sequence.

> I'll wait for the results of your investigation, but it may be better to withdraw the patch.

The issue was in the unwinding code in the libgcc_s.so. I haven't figured
out the exact mechanism, but found that emitting a separate note for each
a1 change fixes it.

-- 
Thanks.
-- Max

  reply	other threads:[~2023-01-06  6:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <04a89dbf-c2a3-5dcb-8949-77569a1ad169.ref@yahoo.co.jp>
2023-01-05  8:40 ` Takayuki 'January June' Suwa
2023-01-05 21:32   ` Max Filippov
2023-01-06  3:34     ` Takayuki 'January June' Suwa
2023-01-06  6:26       ` Max Filippov [this message]
2023-01-06  6:57         ` Takayuki 'January June' Suwa
2023-01-06  8:05           ` Max Filippov
2023-01-07  2:54             ` Takayuki 'January June' Suwa

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=CAMo8BfJkid+u8553c_76UUp52g8p8r8cbRWNAkLyLsjnPQkiXA@mail.gmail.com \
    --to=jcmvbkbc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jjsuwa_sys3175@yahoo.co.jp \
    /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).