From: Richard Sandiford <rdsandiford@googlemail.com>
To: gcc-patches@gcc.gnu.org
Subject: PR 48826: NOTE_INSN_CALL_ARG_LOCATION vs. define_split
Date: Mon, 23 May 2011 02:07:00 -0000 [thread overview]
Message-ID: <87tycm4ewx.fsf@firetop.home> (raw)
In PR 44826, we split a pre-reload call into another call followed
by a load of GP. The problem is that we're running the split pass after
var-tracking, and the original call had a NOTE_INSN_CALL_ARG_LOCATION
attached to it. We need to move the note to the new call, just like we
already move other properties of the call.
This shows up on 32-bit MIPS GNU/Linux at -O -g, because the first
post-epilogue scheduling pass is after var tracking. It doesn't
show up on -O2 and above because an earlier pass does the split.
I think the bug could in principle trigger on other targets with
call-clobbered GPs (e.g. some variants of Alpha, ia64 and PA).
However, most other ports split on reload_completed, whereas MIPS
does it on epilogue_completed, so perhaps it really is only MIPS.
Tested on mips-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
gcc/
PR rtl-optimization/48826
* emit-rtl.c (try_split): When splitting a call that is followed
by a NOTE_INSN_CALL_ARG_LOCATION, move the note after the new call.
Index: gcc/emit-rtl.c
===================================================================
--- gcc/emit-rtl.c 2011-05-22 17:13:06.000000000 +0100
+++ gcc/emit-rtl.c 2011-05-22 20:37:09.000000000 +0100
@@ -3476,11 +3476,27 @@ try_split (rtx pat, rtx trial, int last)
for (insn = insn_last; insn ; insn = PREV_INSN (insn))
if (CALL_P (insn))
{
+ rtx next;
rtx *p = &CALL_INSN_FUNCTION_USAGE (insn);
while (*p)
p = &XEXP (*p, 1);
*p = CALL_INSN_FUNCTION_USAGE (trial);
SIBLING_CALL_P (insn) = SIBLING_CALL_P (trial);
+ /* If the new call is the last instruction in the sequence,
+ it will effectively replace the old call in-situ. Otherwise
+ we must move any following NOTE_INSN_CALL_ARG_LOCATION note
+ so that it comes immediately after the new call. */
+ if (NEXT_INSN (insn))
+ {
+ next = NEXT_INSN (trial);
+ if (next
+ && NOTE_P (next)
+ && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
+ {
+ remove_insn (next);
+ add_insn_after (next, insn, NULL);
+ }
+ }
}
}
next reply other threads:[~2011-05-22 21:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-23 2:07 Richard Sandiford [this message]
2011-05-23 9:30 ` Eric Botcazou
2011-05-23 20:16 ` Richard Sandiford
2011-05-23 22:46 ` Eric Botcazou
2011-05-29 1:07 ` Richard Sandiford
2011-05-29 14:31 ` 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=87tycm4ewx.fsf@firetop.home \
--to=rdsandiford@googlemail.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).