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