This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] reorg.c janitor patch 2: handle DEBUG_INSN


Eric Botcazou <ebotcazou@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]