Re: [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping

[Jeff Law <law at redhat dot com>]

On 02/18/15 01:03, Maxim Kuvyrkov wrote:
> The way SCHED_GROUP_P instructions have been handled historically is
> by combination of two artifacts: (1) removing all dependencies for
> instructions inside SCHED_GROUP sequence but the one to next insn,
> and (2) maintaining a fast track for SCHED_GROUP insns that ensures
> that once the first SCHED_GROUP insn is issued, scheduler does
> nothing but issuing the single dependent insn of the current one.
The "fast track" was actually implemented by just advancing the cycle 
counter forward by an appropriate number of cycles of a SCHED_GROUP_P 
insn got queued.   So the next iteration of the loop, the SCHED_GROUP_P 
is magically ready along with potentially other instructions that had 
been queued prior to the SCHED_GROUP_P insn.

But that was OK (of course) because the SCHED_GROUP_P insns get priority 
over everything else that is ready on a particular cycle.

Bernd's work broke because the SCHED_GROUP_P insn got queued, but the 
cycle counter only moved forward one tick.  Thus previously queued insns 
could become ready while the SCHED_GROUP_P insn was waiting.

My fix restores correctness by queuing the SCHED_GROUP_P insn for just a 
single cycle (it may get queued again, but that's OK as everything else 
that's ready in the same cycle as a queued SCHED_GROUP_P insn will get 
re-queued as well).  It's marginally less compile-time efficient, but it 
was an easy, clean fix.

jeff