From: Bin Cheng <Bin.Cheng@arm.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: nd <nd@arm.com>
Subject: [PATCH GCC]Check tieable TRUNCATE only if inner rtx is register
Date: Fri, 19 May 2017 16:07:00 -0000 [thread overview]
Message-ID: <VI1PR0802MB217616EFF8D5064D6F27F00FE7E50@VI1PR0802MB2176.eurprd08.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]
Hi,
Revision 247881 possibly exposes bug in RTL or ARM backend, while the change itself
may be incomplete too. Given a TRUNCATE rtx with complicated sub-rtx, backend may
want to know the complicated sub-rtx happens in context of TRUNCATE in order to give
different costs. This patch adds restriction only checking tieable TRUNCATE if its operand
is register. This is enough for middle-end, it builds up (truncate:SI (reg:DI)) in order to setup
conversion cost for GIMPLE optimizations. On the other hand, targets like i386/arm don't
handle register truncation at the moment.
Note, this patch minimize the impact of cost change and workaround PR80754 for now.
So far the effect of change in r247881 is to allow smulsi3_highpart_v6 pattern to be used
rather than smullsidi, which means it actually gives RA more free in choosing registers.
If it's because of the cost change that smulsi3_highpart_v6 is now preferred, it could be
suggesting that r247881 is good. Anyway, it's just my guess before looking into rtl passes.
Bootstrap and test ongoing. Is it OK?
2017-05-13 Bin Cheng <bin.cheng@arm.com>
* rtlanal.c (rtx_cost): Check tieable TRUNCATE only if inner rtx
is register.
[-- Attachment #2: pr80754.txt --]
[-- Type: text/plain, Size: 544 bytes --]
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index d9f57c3..b211efb 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -4165,7 +4165,10 @@ rtx_cost (rtx x, machine_mode mode, enum rtx_code outer_code,
break;
case TRUNCATE:
- if (MODES_TIEABLE_P (mode, GET_MODE (XEXP (x, 0))))
+ /* If inner rtx isn't register, fall through and call target hook.
+ Backend may want to know that sub-rtx is in truncate. */
+ if (REG_P (XEXP (x, 0))
+ && MODES_TIEABLE_P (mode, GET_MODE (XEXP (x, 0))))
{
total = 0;
break;
next reply other threads:[~2017-05-19 15:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 16:07 Bin Cheng [this message]
2017-05-23 14:54 ` Richard Sandiford
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=VI1PR0802MB217616EFF8D5064D6F27F00FE7E50@VI1PR0802MB2176.eurprd08.prod.outlook.com \
--to=bin.cheng@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=nd@arm.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).