https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #16 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- Sorry it took me so long to react, I'd missed the question. IIRC the scheduler was the hardest part of GCC to make work with debug insns. The general strategy is that nondebug insns never depend on debug insns, while debug insns depend on the preceding insns and on the previous debug insn, besides the deps it would have if it were a regular insn. This generally enables debug insns to be issued right after the insn that produces the side effect it notes, but if the nondebug insn is pulled ahead, the ordering WRT other debug insns keeps the debug views consistent with the ordering of side effects in source code. They shouldn't, however, prevent a nondebug insn from being pulled ahead of them. We take note of conflicts to invalidate the expression in the debug insn, rather than to prevent reordering. That's the theory, and there have been plenty of deviations from that caught by -fcompare-debug and fixed during the VTA development, but it was tricky enough that selective scheduling could never be made VTA-safe. It's not what's in use for x86, though, so this must be something else.
