[PR debug/41535] reset debug insns affected by scheduling

Alexandre Oliva aoliva@redhat.com
Thu Oct 15 07:23:00 GMT 2009

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

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

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

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-sched-deps-debug.patch
Type: text/x-diff
Size: 10112 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091015/456518ee/attachment.bin>
-------------- next part --------------

Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

More information about the Gcc-patches mailing list