This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]