The logic introduced in the scheduler to keep debug insns at about the
right place (as early as possible given deps on operands, on the prior
debug insn and on the prior nondebug insn), while preventing them from
affecting the scheduling of nondebug insns (avoiding any dependencies of
nondebug insns on debug insns), ended up enabling nondebug insns that
set registers or memory locations to be moved before debug insns that
expected their prior values.  Oops.

This patch enables nondebug insns to “depend” on debug insns, but these
dependencies are handled in a special way: they don't stop the nondebug
insn from being scheduled.  Rather, they enable the nondebug insn, once
scheduled, to quickly reset debug insns that remain as unresolved
dependencies.

To avoid using up more memory and complicating scheduler logic, I didn't
add more dependency lists.  Instead, I've arranged for “debug deps”,
i.e., those in which a nondebug insn depends on a debug insn, to be
added to the dependency lists after all nondebug deps.  This enables us
to quickly verify that the dependency lists are “empty” (save for debug
deps).

As expected, this situation is quite uncommon.  There are no more than a
few hundred hits building stage2 of GCC with all languages enabled.
Thus, although attempting to preserve the debug information at hand
might be possible, I decided it wasn't worth it, and coded the scheduler
to just drop it on the floor.

This is the current implementation.  I'm a bit undecided as to whether
to implement the insertion of debug deps in dep lists in this
simple-minded way, which may exhibit O(n^2) behavior if long lists of
debug deps arise, or to compute all deps without regard to such
ordering, and then reorder them at the end (won't work with incremental
computation of dependencies, as in sel-sched IIRC), or when computing
list lengths, or perhaps even discounting them in the list length
counter.

I'm not sufficiently proficient in the schedulers to tell which is best
without trying them all.  Any advice from sched experts?


I'm still testing this patch, but if it looks reasonable, is it ok to
install if it passes regstrap?