public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@imgtec.com>
To: Bernd Schmidt <bschmidt@redhat.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: RFC: Patch to allow spill slot alignment greater than the stack alignment
Date: Tue, 06 Oct 2015 18:02:00 -0000	[thread overview]
Message-ID: <1444154522.8687.248.camel@ubuntu-sellcey> (raw)
In-Reply-To: <5613EB22.4020505@redhat.com>

On Tue, 2015-10-06 at 17:39 +0200, Bernd Schmidt wrote:

> 
> Did your tag that copy as RTX_FRAME_RELATED? I'd expect dwarf2cfi would 
> ignore instructions with that bit unset. There's even a comment 
> indicating arm does something like this:

Yes, I had marked it as RTX_FRAME_RELATED.  When I took that out things
looked better (well, maybe just different).

If I remove that and I change Rule #16 to handle an AND with a register
I get odd looking .cfi stuff.  The AND instruction (which is marked with
RTX_FRAME_RELATED) seems to generate these cfi_escape macros:

	.cfi_escape 0x10,0x1f,0x2,0x8e,0x7c
	.cfi_escape 0x10,0x1e,0x2,0x8e,0x78
	.cfi_escape 0x10,0xc,0x2,0x8e,0x74

which are meaningless to me.  What I found works better is to skip the
dwarf2cfi.c changes and explicitly attach this note to the AND
instruction:

      cfi_note = alloc_reg_note (REG_CFA_DEF_CFA, stack_pointer_rtx, NULL_RTX);
      REG_NOTES (insn) = cfi_note;

When I do this the only unexpected test suite execution failures I see
are ones that call the C++ set_unexpected function.

FYI: The reason I was copying the stack pointer to another register was
to use that other register as my argument pointer (needed after the
stack pointer got aligned) and to use it to restore the stack pointer at
the end of the function for normal returns.

Steve Ellcey
sellcey@imgtec.com

  reply	other threads:[~2015-10-06 18:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 20:58 Steve Ellcey
2015-10-05  8:41 ` Bernd Schmidt
2015-10-05 16:10   ` Steve Ellcey
2015-10-05 16:21     ` H.J. Lu
2015-10-05 16:46       ` Steve Ellcey
2015-10-05 16:57         ` H.J. Lu
2015-10-06 15:30           ` Steve Ellcey
2015-10-06 15:35             ` H.J. Lu
2015-10-06 15:39             ` Bernd Schmidt
2015-10-06 18:02               ` Steve Ellcey [this message]
2015-10-06 18:10                 ` H.J. Lu
2015-10-06 18:32                   ` Steve Ellcey
2015-10-06 18:38                     ` H.J. Lu
2015-10-09 22:22                   ` Steve Ellcey
2015-10-09 22:36                     ` H.J. Lu
2015-10-09 22:42                       ` Steve Ellcey
2015-10-09 23:35                         ` H.J. Lu
2015-10-06 23:24                 ` Bernd Schmidt
2015-10-05 17:02         ` Bernd Schmidt
2015-10-05 17:51         ` Mike Stump

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=1444154522.8687.248.camel@ubuntu-sellcey \
    --to=sellcey@imgtec.com \
    --cc=bschmidt@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    /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).