Re: gcc 3.4 regression: sched2 moving "may throw" instructions intoepilogue

[Andrew Haley <aph at redhat dot com>]

Jim Wilson writes:
 > Andrew Haley wrote:
 > > Insns that may trap must not be move into the epilogue, because stack
 > > unwinding when throwing exceptions will not work correctly.
 > 
 > It could work if we emitted unwind info for epilogues.  Currently we 
 > don't do so for targets that use the DWARF2 CFI-based unwind info.  We 
 > do for targets that use the IA-64 unwind info though.
 > 
 > An alternative would be to emit a blockage insn before the epilogue when 
 > -fnon-call-exceptions is used.  This will unnecessarily reduce 
 > performance for targets that have epilogue unwind info, probably only 
 > IA-64 at this point, but should make your testcase work.
 > 
 > For the blockage insn, you can use the hack that is used in 
 > expand_builtin_setjmp_receiver and expand_nl_goto_receiver, which is to 
 > emit an ASM_INPUT insn.

Thanks for the reply.

Is that right, though?  It's only trapping instructions that mustn't
be moved into the epilogue, not all instructions.  This solution
sounds like it would be an all-round performance loser.

Andrew.