This is the mail archive of the
mailing list for the GCC project.
Re: Fill more delay slots in conditional returns
- From: Jeff Law <law at redhat dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 29 Mar 2013 14:03:07 -0600
- Subject: Re: Fill more delay slots in conditional returns
- References: <1769120 dot Os7kk4Zj9I at polaris>
On 03/25/2013 05:25 AM, Eric Botcazou wrote:
I'm not sure what this is supposed to do. How is pat == target ever
going to be true when ANY_RETURN_P (pat) is true? Isn't target supposed
to be a CODE_LABEL or NULL? What am I missing?
for a private port with conditional returns and delay slots, only the simple
algorithm (fill_simple_delay_slots) is able to fill the slots. It's because
get_branch_condition just punts on conditional returns.
Fixed thusly. While I investigated this, I realized that the block of code in
fill_simple_delay_slots between line 2097 and line 2274 is dead for JUMP insns
(and has been so for a long time, which is consistent with various comments in
the code, for example the head comment of fill_eager_delay_slots) so the patch
also cleans it up (modulo the formatting to make the patch readable).
Jeff, any objections? Tested on SPARC/Solaris, no difference in the generated
code at -O2 for the gcc.c-torture/compile testsuite.
2013-03-25 Eric Botcazou<firstname.lastname@example.org>
* reorg.c (get_branch_condition): Deal with conditional returns.
(fill_simple_delay_slots): Remove dead code dealing with jumps.
-- Eric Botcazou
--- reorg.c (revision 196816)
+++ reorg.c (working copy)
@@ -921,8 +921,8 @@ get_branch_condition (rtx insn, rtx targ
if (condjump_in_parallel_p (insn))
pat = XVECEXP (pat, 0, 0);
- if (ANY_RETURN_P (pat))
- return pat == target ? const_true_rtx : 0;
+ if (ANY_RETURN_P (pat) && pat == target)
+ return const_true_rtx;
What does the RTL for your conditional return look like
(if_then_else (cond) (pc) (return))
Where the (pc) and (return) can be reversed as well? That's what the
later hunks in get_branch_condition seem to imply.
Maybe if I saw the RTL that first hunk would make sense. It feels like
I'm missing something.
The cleanup stuff is OK, check that in whenver you'd like.