On 09/13/11 13:37, Richard Sandiford wrote: > 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.
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... Bernd
