Re: [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping

[James Greenhalgh <james dot greenhalgh at arm dot com>]

On Mon, Feb 09, 2015 at 11:16:56PM +0000, Jeff Law wrote:
> On 02/06/15 05:24, James Greenhalgh wrote:
> >
> > ---
> > 2015-02-06  James Greenhalgh  <james.greenhalgh@arm.com>
> >
> > 	* haifa-sched.c (recompute_todo_spec): After applying a
> > 	replacement and cancelling a dependency, also clear the
> > 	SCHED_GROUP_P flag.
> My worry here would be that we might be clearing a SCHED_GROUP_P that
> had been set for some reason other than macro-fusion.

Yeah, I also had this worry. This patch tackles the problem from the
other direction. If we see a SCHED_GROUP_P on an insn, treat it as a
hard dependency, and don't try to rewrite it. I think this will always
be "safe" but it might pessimize if the dependency breaker would have
resulted in better code generation.

I don't think this gives you anything towards fixing your bug, but
it clears mine.

I've bootstrapped and tested on x86_64-unknown-linux-gnu with no
issues and given it a quick check on the problem code from before,
where it has the desired impact.

Thanks,
James

---
2015-02-10  James Greenhalgh  <james.greenhalgh@arm.com>

	* haifa-sched.c (recompute_todo_spec): Treat SCHED_GROUP_P
	as forcing a HARD_DEP between instructions, thereby
	disallowing rewriting to break dependencies.

diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 75d2421..06444de 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -1233,6 +1233,11 @@ recompute_todo_spec (rtx_insn *next, bool for_backtrack)
   if (!sd_lists_empty_p (next, SD_LIST_HARD_BACK))
     return HARD_DEP;
 
+  /* If NEXT is intended to sit adjacent to this instruction, we don't
+     want to try to break any dependencies.  Treat it as a HARD_DEP.  */
+  if (SCHED_GROUP_P (next))
+    return HARD_DEP;
+
   /* Now we've got NEXT with speculative deps only.
      1. Look at the deps to see what we have to do.
      2. Check if we can do 'todo'.  */