On May 13, 2011, at 4:57 PM, Eric Botcazou wrote:
>> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
>> right? From the definition of REG_DEAD, it seems that rewriting a later
>> insns to use register x means that a preceding (REG_DEAD x) needs to be
>> deleted. Or moved to the later insn, perhaps.
>
> If the pass doesn't consume REG_DEAD/REG_UNUSED notes, it doesn't have to
> keep
> them up-to-date. Instead, passes that consume them must
> df_note_add_problem()
> on entry. For the generic reorg (delay slot filling) pass, this is done in
> rest_of_pass_free_cfg.
The regcprop pass doesn't look at notes and doesn't change them. But it does
create references to registers in insns after the one where the register was
marked dead.
A later pass (machdep) relies on the notes, so the fact that the actual
register liveness no longer matches what the REG_DEAD notes imply seems to be a
problem.
The comment on mark_target_live_regs() in resource.c says:
We have to be careful when using REG_DEAD notes because they are not
updated by such things as find_equiv_reg. So keep track of registers
marked as dead that haven't been assigned to, and mark them dead at the
next CODE_LABEL since reload and jump won't propagate values across labels.
What regcprop does seems to contradict the assumption stated here -- that a
register marked dead is definitely not referenced in an insns after a label
after the REG_DEAD.
I was thinking about having regcprop move the REG_DEAD notice to the
instructions whose register is rewritten if the new register was marked dead in
an earlier insn. Would that make sense?
If not, what else can I do here? It's a pretty nasty bug, wrong code that
crashes the application with an addressing exception.
paul
