On Feb 10, 2015, at 7:16 AM, Jeff Law <l...@redhat.com> 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. > > 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). -- Maxim Kuvyrkov www.linaro.org
