This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue
Jim Wilson writes:
> Andrew Haley wrote:
> > 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.
>
> I don't see any obvious way to restrict this to only trapping insns.
Well, there seem to be a number of places where this blockage insn
could be emitted, and I can't decide which would be the best. It
could either be the start of the epilogue or the end of the funtion
proper. This is my best guess.
OK for mainline and branches?
Andrew.
2004-03-05 Andrew Haley <aph@redhat.com>
* function.c (expand_function_end): Emit a blockage insn before
the epilogue when -fnon-call-exceptions is used.
Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.496
diff -u -r1.496 function.c
--- function.c 19 Feb 2004 08:00:47 -0000 1.496
+++ function.c 5 Mar 2004 14:44:31 -0000
@@ -7020,6 +7020,14 @@
clear_pending_stack_adjust ();
do_pending_stack_adjust ();
+ /* @@@ This is a kludge. We want to ensure that instructions that
+ may trap are not moved into the epilogue by scheduling, because
+ we don't always emit unwind information for the epilogue.
+ However, not all machine descriptions define a blockage insn, so
+ emit an ASM_INPUT to act as one. */
+ if (flag_non_call_exceptions)
+ emit_insn (gen_rtx_ASM_INPUT (VOIDmode, ""));
+
/* Mark the end of the function body.
If control reaches this insn, the function can drop through
without returning a value. */