Initial shrink-wrapping patch

[Richard Sandiford]

Bernd Schmidt <bernds@codesourcery.com> writes:
> On 09/13/11 13:37, Richard Sandiford wrote:
>> Bernd Schmidt <bernds_cb1@t-online.de> writes:
>>> On 09/13/11 10:35, Richard Sandiford wrote:
>>>>> Also, it turns out I need to pretend that trap_if requires the prologue
>>>>> due to the testcase you also ran across, so a for_each_rtx walk is
>>>>> required anyway.
>>>>
>>>> Why does TRAP_IF inherently need a prologue though?  The CFA information
>>>> should be correct regardless.
>>>
>>> It is until you cross-jump the two trap_ifs. So we have to disable
>>> either one of the two optimizations for them.
>> 
>> But trap_if seems to be tackling it at the wrong level.  AIUI, the
>> problem is that we usually rely on the different return JUMP_LABELs
>> to stop unwrapped blocks from being merged with wrapped blocks,
>> and that that falls down if there is no return.  And although it's
>> likely always true in practice, it seems wrong in principle to assume
>> that nothing after prologue/epilogue generation will discover new
>> points of no return.
>
> Well, I know of nothing that could lead to such a case. Maybe we should
> worry about it when we get there? At the moment, only if_trap is known
> to cause us problems and it's easy enough to just deal with it by
> turning off either shrink-wrapping or crossjumping. I don't much care
> which...

It just feels like checking for trap_if or turning off cross-jumping
are working around problems in the representation of shrink-wrapped
functions.  There should be something in the IL to say that those
two blocks cannot be merged for CFI reasons.  Maybe two flags on
the basic block to say whether they start (resp. end) with the
"wrapped" version of the CFI?  (Which unfortunately would need
to be checked explicitly.)

OTOH, if another reviewer thinks that's unreasnable, I'll happily
defer to them.

Richard