This is the mail archive of the
mailing list for the GCC project.
Re: [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: law at redhat dot com, vmakarov at redhat dot com, maxim dot kuvyrkov at linaro dot org
- Date: Wed, 11 Feb 2015 09:20:57 +0000
- Subject: Re: [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping
- Authentication-results: sourceware.org; auth=none
- References: <54D93FE8 dot 3020505 at redhat 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 <firstname.lastname@example.org>
> > * 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.
2015-02-10 James Greenhalgh <email@example.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
@@ -1233,6 +1233,11 @@ recompute_todo_spec (rtx_insn *next, bool for_backtrack)
if (!sd_lists_empty_p (next, SD_LIST_HARD_BACK))
+ /* 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'. */