[RFC/CFT] Hookize TARGET_UNWIND_INFO and related macros

[Andrey Belevantsev]

On 30.09.2010 20:24, Richard Henderson wrote:
> On 09/30/2010 05:46 AM, Andrey Belevantsev wrote:
>> The scheduler lifts an insn (ar.pfs = r35) from the epilogue creating
>> a bookkeeping copy and thus creating an extra NOTE_INSN_EPILOGUE_BEG
>> note. If this is not permitted now, what do I check to prevent that
>> happening?
>
> The NOTE_INSN_EPILOGUE_BEG needs to be strictly paired with the
> return/sibcall insn that exits the function.  In practice I think
> this means it cannot be moved out of the (copy of) the block into
> which it was emitted.
>
> It will also be an error to move an insn marked RTX_FRAME_RELATED_P
> before the EPILOGUE_BEG note.  The rest of the insns emitted with
> the epilogue don't really matter.
>
> In the case of the ar.pfs move -- which isn't FRAME_RELATED -- I
> would say that the best thing to do is simply remove it from the
> epilogue_insn_hash and not move the EPILOGUE_BEG note.  This will
> require a new interface in function.c.

I was wrong, the problem was not in creating an extra copy of 
NOTE_INSN_EPILOGUE_BEG, but rather in moving one note up such that there 
was a control flow path with two such notes (the function had two returns 
from the beginning).

Anyway, currently any prologue_epilogue_contains insn can be moved out of 
its block if this would not require a bookkeeping copy.  This is not enough 
to prevent the above cases to happen, thus I can stop moving both 
RTX_FRAME_RELATED_P insns and NOTE_INSN_EPILOGUE_BEG notes from their basic 
block.  For the latter, I need to stop moving the insn to which the note 
was attached in remove_notes, and this happen to be the non-frame related 
ar.pfs move; removing this move from epilogue_insn_hash would not help as 
this would only increase the scheduling freedom that we have.

The patch implementing the above in sel-sched works for the test case. 
Does this sound right to you?

Andrey