Bernd Schmidt <bernds_...@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.

So yeah, maybe trying to disable cross-jumping in this sort of situation
(and hopefully only in this sort of situation) is the right way to go.
It would be good if we could represent it in the rtl somehow, so that
the current analysis code will think that the two blocks aren't equal,
without us having to remember to add a special check everywhere that
this sort of thing could occur.  Not sure how feasible that is though...

Richard

Reply via email to