Eric Botcazou <ebotca...@adacore.com> writes: >> If that is true, then why are there so many post var-tracking passes >> using NONDEBUG_INSN_P and/or looking for the DEBUG_INSN code? See e.g. >> shorten_branches, reorg.c, various machine reorgs, etc. > > They are very likely overzealous. > >> For example from reorg.c:redundant_insn() in the loop "/* Scan >> backwards looking for a match. */": >> >> 151731 nemet if (!NONDEBUG_INSN_P (trial)) >> 99 kenner continue; >> 151731 nemet --insns_to_search; >> >> This was introduced to fix PR41349. Apparently DEBUG_INSN live on >> beyond var-tracking...? > > I think that the fix for this PR was really about NOTEs and not DEBUG_INSNs. > > I'm going to test the following patchlet on the SPARC:
Steve hit a case where running vartracking before dbr_schedule caused a bootstrap failure on MIPS. On targets without delay slots, that kind of bug has been fixed by: /* Variable tracking should be run after all optimizations which change order of insns. It also needs a valid CFG. */ #undef TARGET_DELAY_VARTRACK #define TARGET_DELAY_VARTRACK true But obviously we can't do that with dbr_schedule, since it changes the order of insns but runs with the CFG pulled down. In the long term it would be good to replace dbr_schedule altogether, but in the medium term I thought we might want to update it so that it can run before vartracking. Richard
