http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51471
--- Comment #13 from vries at gcc dot gnu.org 2011-12-19 13:23:41 UTC ---
(In reply to comment #11)
> This is the patch which I am testing:
> Index: genattrtab.c
> ===================================================================
> --- genattrtab.c (revision 182342)
> +++ genattrtab.c (working copy)
> @@ -4280,6 +4280,11 @@ write_eligible_delay (const char *kind)
> printf (" if (!INSN_P (candidate_insn))\n");
> printf (" return 0;\n");
> printf ("\n");
> + /* Frame related instructions are hard to put in the delay slot for
> + debugging info reasons. */
> + printf (" if (RTX_FRAME_RELATED_P (candidate_insn))\n");
> + printf (" return 0;\n");
> + printf ("\n");
>
> /* If more than one delay type, find out which type the delay insn is. */
What is the exact reason we're completely avoiding scheduling frame-related
insns in delay slots? Why don't we try to fix it like this?:
...
Index: src/gcc-mainline/gcc/reorg.c
===================================================================
--- src/gcc-mainline/gcc/reorg.c (revision 182341)
+++ src/gcc-mainline/gcc/reorg.c (working copy)
@@ -2716,7 +2716,7 @@ fill_slots_from_thread (rtx insn, rtx co
if (!must_annul
&& (condition == const_true_rtx
|| (! insn_sets_resource_p (trial, &opposite_needed, true)
- && ! may_trap_or_fault_p (pat))))
+ && ! may_trap_or_fault_p (pat) && !RTX_FRAME_RELATED_P
(trial))))
{
old_trial = trial;
trial = try_split (pat, trial, 0);
...
AFAIU, the only thing causing problems is frame-related insns being speculated.
