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: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- To: Jeff Law <law at redhat dot com>
- Cc: James Greenhalgh <james dot greenhalgh at arm dot com>, gcc-patches at gcc dot gnu dot org, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Tue, 10 Feb 2015 21:21:52 +0800
- 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> <54D93FE8 dot 3020505 at redhat dot com>
On Feb 10, 2015, at 7:16 AM, Jeff Law <email@example.com> 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.
> 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).
Scheduler is not supposed to look at either queue or ready list when scheduling instructions in the SCHED_GROUP. There used to be code in schedule_insn() (this function is refactored/gone now, I think), but the logic should have stayed their.
I'm at a conference at the moment (Linaro Connect) and can look at this on Monday/Tuesday (Feb 16/17).