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: Jeff Law <law at redhat dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>, gcc-patches at gcc dot gnu dot org
- Cc: vmakarov at redhat dot com, maxim dot kuvyrkov at linaro dot org
- Date: Mon, 09 Feb 2015 16:16:56 -0700
- Subject: Re: [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping
- Authentication-results: sourceware.org; auth=none
- References: <1423225443-14362-1-git-send-email-james dot greenhalgh at arm dot com>
On 02/06/15 05:24, James Greenhalgh wrote:
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.
2015-02-06 James Greenhalgh <email@example.com>
* haifa-sched.c (recompute_todo_spec): After applying a
replacement and cancelling a dependency, also clear the
It makes me wonder if we really want another bit to carry the "these
must remain consecutive for correctness" vs "please keep these together
so something later can optimize better" characteristics.
I'm also tracking a bug where we mis-handle SCHED_GROUP_P when there's a
hazard of some sort between the first and second in the group. In that
case we fire the first insn, then queue the second. If some other insn
that had been queued earlier becomes ready during the cycles between
where the first insn fired and 2nd insn is scheduled to fire, then we'll
break the SCHED_GROUP_P relationship. For the particular case I'm
looking at, it's a correctness issue (cc0 machine and we end up
splitting the cc0-setter and cc0-user).