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.greenha...@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.greenha...@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'. */
