From: Richard Earnshaw <rearnsha@arm.com>
To: Bernd Schmidt <bernds@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>
Subject: Re: [ARM] Fix PR49641
Date: Tue, 18 Oct 2011 14:26:00 -0000 [thread overview]
Message-ID: <4E9D79F7.8030407@arm.com> (raw)
In-Reply-To: <4E9D754A.4040804@codesourcery.com>
On 18/10/11 13:47, Bernd Schmidt wrote:
> On 10/18/11 14:30, Richard Earnshaw wrote:
>> Well, if that's the case why do we need to test for Thumb1 at all? And
>> why do we only enable write-back for Thumb1? other ISA variants can
>> also do that (I know that Thumb1 requires write-back, but it's
>> optionally available for the other ISA flavours).
>
> We're not trying to generate a writeback sequence with our peepholes.
> The problem is that on Thumb, that's the only instruction available, and
> we want to make use of it if possible (i.e. register dead afterwards etc.).
>
>
> Bernd
>
OK, I understand now. However, I think it's misleading to talk about
thumb1 directly here -- it implies that this doesn't apply in other cases.
A better patch, would be (I think)
--- gcc/config/arm/arm.c (revision 175906)
+++ gcc/config/arm/arm.c (working copy)
@@ -9950,7 +9950,9 @@ store_multiple_sequence (rtx *operands,
/* If it isn't an integer register, then we can't do this. */
if (unsorted_regs[i] < 0
|| (TARGET_THUMB1 && unsorted_regs[i] > LAST_LO_REGNUM)
- || (TARGET_THUMB2 && unsorted_regs[i] == base_reg)
+ /* The effects are unpredictable if the base reg is
+ both updated and stored. */
+ || (base_writeback && unsorted_regs[i] == base_reg)
|| (TARGET_THUMB2 && unsorted_regs[i] == SP_REGNUM)
|| unsorted_regs[i] > 14)
return 0;
and then initialize base_writeback at the entry to the function (I
presume that currently we would just set it to be TARGET_THUMB1),
perhaps with a comment saying that we don't currently support
base_writeback for other ISA variants.
R.
next prev parent reply other threads:[~2011-10-18 13:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 20:08 Bernd Schmidt
2011-07-13 14:31 ` Richard Earnshaw
2011-10-14 13:57 ` Bernd Schmidt
2011-10-17 13:34 ` Richard Earnshaw
2011-10-18 12:26 ` Bernd Schmidt
2011-10-18 12:59 ` Richard Earnshaw
2011-10-18 14:24 ` Bernd Schmidt
2011-10-18 14:26 ` Richard Earnshaw [this message]
2011-10-24 14:00 ` Sebastian Huber
2011-10-25 17:52 ` Richard Earnshaw
2011-10-31 11:53 ` Sebastian Huber
2011-11-08 8:35 ` Sebastian Huber
2011-11-16 10:41 ` Sebastian Huber
2011-11-16 19:05 ` Richard Earnshaw
[not found] ` <4E1DA543.4030000@arm.com>
2011-07-25 17:00 ` Bernd Schmidt
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=4E9D79F7.8030407@arm.com \
--to=rearnsha@arm.com \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=bernds@codesourcery.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).