Re: invalid delayed slot filling

[Ian Lance Taylor <iant at google dot com>]

Christian BRUEL <christian.bruel@st.com> writes:

> that's the point, 'mark_target_live_regs' doesn't scan the insns until
> the return statement, but until 'stop_insn' that is the first insns
> after the delayed branch (the first insn in the fall thru block), so
> 'end_of_function_needs' wasn't looked at.

That shouldn't matter.  mark_target_live_regs starts with the set of
register live at the start of the block.  That set has already been
computed and should be correct.  In particular, if FPSCR is live at
the start of the block, it should be in that set.  Then
mark_target_live_regs walks through the insns.  For each register it
finds the dies, it removes it from the set of live registers.  For
each register it finds that comes alive, it adds it to the set of live
registers.

I don't know why you are focusing on the registers live in the
epilogue.  The registers live in the epilogue of a function being
called are not necessarily live in the function making the call.

> but ... I'm realizing that fpscr_reg is not in the global_regs set,
> which is correctly looked at at the call stmt.
> 
> So updating CONDITIONAL_REGISTER_USAGE in sh.md to have FPSCR_REG a
> global_regs cleanly seem to fix this problem.

I'm sorry, that is not correct either.  The global_regs array exists
only to hold global register variables declared by the user.  It would
not be correct for a backend to add an entry to that array.

Let me ask again: why is the register considered to be dead?

Ian