public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Chung-Lin Tang <cltang@codesourcery.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Richard Earnshaw <rearnsha@arm.com>,
	 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Subject: [patch, ARM] Fix PR42017, LR not used in leaf functions
Date: Thu, 28 Apr 2011 06:34:00 -0000	[thread overview]
Message-ID: <4DB8DB6D.1050107@codesourcery.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

Hi, this patch tries to solve the problem of the LR register not
being used in leaf functions on ARM.

Looking at the dumps, it shows that register 14 (lr) conflicts with all
allocnos throughout the entire leaf procedure. A little digging shows
that lr is present in the OBJECT_CONFLICT_HARD_REGS() set of all
allocnos, which suggests that this may manifest from a convention of
some sort the code is currently following.

It turns out that, during the IRA liveness computations, the DF initing
of live hard regs, starting from the bottom end of the function, adds
EPILOGUE_USES right from the start. With no call sites to kill its
liveness, the entire procedure is prohibited from using LR at all.

This problem may also be more serious than just leaf functions.
Theoretically, this may affect all allocnos that happen to completely
lie on paths that reach the end of function without a call site, even in
non-leaf functions. All these are deprived of LR as an usable register.

My fix here simply adds 'reload_completed' as an additional condition
for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
valid, as correct LR save/restoring is handled by the epilogue/prologue
code; it should be safe for IRA to treat it as a normal call-used register.

I did a cross-test on QEMU with clean results, plus a successful native
bootstrap on a Pandaboard. Is this okay for trunk?

Thanks,
Chung-Lin

2011-04-28  Chung-Lin Tang  <cltang@codesourcery.com>

	PR target/42017
	* config/arm/arm.h (EPILOGUE_USES): Only return true
	for LR_REGNUM after reload_completed.


[-- Attachment #2: arm-epilogue_uses.diff --]
[-- Type: text/plain, Size: 491 bytes --]

Index: config/arm/arm.h
===================================================================
--- config/arm/arm.h	(revision 173046)
+++ config/arm/arm.h	(working copy)
@@ -1627,7 +1627,7 @@
    frame.  */
 #define EXIT_IGNORE_STACK 1
 
-#define EPILOGUE_USES(REGNO) ((REGNO) == LR_REGNUM)
+#define EPILOGUE_USES(REGNO) (reload_completed && (REGNO) == LR_REGNUM)
 
 /* Determine if the epilogue should be output as RTL.
    You should override this if you define FUNCTION_EXTRA_EPILOGUE.  */


             reply	other threads:[~2011-04-28  3:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28  6:34 Chung-Lin Tang [this message]
2011-05-03 13:24 ` Richard Sandiford
2011-05-13 15:26   ` Richard Sandiford
2011-05-17  7:22     ` Chung-Lin Tang
2011-05-20 13:28       ` Ramana Radhakrishnan
2011-05-20 13:49         ` Chung-Lin Tang
2011-05-25 19:03           ` Chung-Lin Tang
2011-06-02  5:00             ` Ping " Chung-Lin Tang
2011-05-19 14:26     ` Eric Botcazou

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=4DB8DB6D.1050107@codesourcery.com \
    --to=cltang@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ramana.radhakrishnan@arm.com \
    --cc=rearnsha@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).