On Mon, Nov 26, 2012 at 07:08:41PM +, Richard Sandiford wrote:
> 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.
var-tracking definitely isn't prepared to handle dbr_sch
Eric Botcazou 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:red
> 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 "/* S
On Sun, Nov 25, 2012 at 11:09 PM, Jakub Jelinek wrote:
> On Sun, Nov 25, 2012 at 12:59:48PM +0100, Steven Bosscher wrote:
>> stop_search_p will reach the default case on DEBUG_INSN, and the
>> default case is "gcc_unreachable()". I suppose this means nobody is
>> using DWARF3+ on a dbr_sched targe
On Sun, Nov 25, 2012 at 12:59:48PM +0100, Steven Bosscher wrote:
> stop_search_p will reach the default case on DEBUG_INSN, and the
> default case is "gcc_unreachable()". I suppose this means nobody is
> using DWARF3+ on a dbr_sched target, it can't possibly ever have
> worked. Eric?
Isn't dbr sch
On Sun, 25 Nov 2012, Steven Bosscher wrote:
> stop_search_p will reach the default case on DEBUG_INSN, and the
> default case is "gcc_unreachable()". I suppose this means nobody is
> using DWARF3+ on a dbr_sched target, it can't possibly ever have
> worked. Eric?
There must be something else (som
