gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Andrew Haley]

g++ is compiling

------------------------------------------------------------------------
typedef struct kkclass;
typedef struct kkclass *jclass;

struct _Jv_VTable
{
  jclass clas;
};

jclass
getClass (void *p)
{
  _Jv_VTable **dt = (_Jv_VTable **) p;
  return (*dt)->clas;
}
------------------------------------------------------------------------

into 

_Z8getClassPv:
.LFB2:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        movl    8(%ebp), %edx
        popl    %ebp
        movl    (%edx), %eax
        movl    (%eax), %eax
        ret
.LFE2:

where, as you can see, the code for the memory access is moved after
the stack adjustment in the epilogue.

This is despite the fact that this code was compiled with
-fnon-call-exceptions and -fno-omit-frame-pointer.

This causes a runtime failure to catch a null pointer exception.
Insns that may trap must not be move into the epilogue, because stack
unwinding when throwing exceptions will not work correctly.

g++ 3.2.2 does this, which is correct:

_Z8getClassPv:
.LFB2:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        movl    8(%ebp), %eax
        movl    (%eax), %eax
        movl    (%eax), %eax
        leave
        ret
.LFE2:

The movement of the popl %ebp instruction seems to be in sched2.

Compiler options used were -O3 -fno-omit-frame-pointer -fnon-call-exceptions.

Andrew.

Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Jim Wilson]

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.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Andrew Haley]

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.

Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Jim Wilson]

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.  We 
could check for trapping insns when moving insns from one block to 
another.  However, in the normal case, the epilogue is not a block of 
its own, as the epilogue does not start with a code label.  Hence there 
is only intra-block movement here, and there are no checks for traps 
when doing intra-block scheduling, except for the obvious case that a 
trapping memory access is considered to conflict with other memory 
accesses.  So you could perhaps handle the trapping mem case with an asm 
that has a memory clobber.  However, that doesn't help you with trapping 
divides.

If you want to handle just trapping insns, then we would need a new kind 
of construct that conflicts only with trapping insns.  Perhaps something 
could be added to asms.  It is already the case that an asm can clobber 
"memory".  Perhaps we can add "traps" to the list.  And then if we see 
this special construct, we prevent any movement of other trapping 
instructions across it.

A more elegant solution is to just emit unwind info for epilogues, which 
the IA-64 port already does.  However, this would require changes to 
many targets, and so it is a lot more work.  It avoids the need for any 
optimizer changes though.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Andrew Haley]

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.  */

Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Jim Wilson]

On Fri, 2004-03-05 at 06:46, Andrew Haley wrote:
> could either be the start of the epilogue or the end of the funtion
> proper.  This is my best guess.

Either seems reasonable for now.  We can always move it later if this
turns out to be the wrong place.

> 	* function.c (expand_function_end): Emit a blockage insn before
> 	the epilogue when -fnon-call-exceptions is used.

OK.

This needs to be sent to gcc-patches.

I prefer the ??? convention over the @@@ one.  ??? is used in 10 places
already in function.c, and there are no uses of @@@.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Gabriel Dos Reis]

Andrew Haley <aph@redhat.com> writes:

| 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?

OK for gcc-3_3-branch is favorably reviewed.

-- Gaby