This is the mail archive of the
mailing list for the GCC project.
Re: [patch] reorg.c janitor patch 2: handle DEBUG_INSN
Eric Botcazou <email@example.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. */
#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.