Re: [Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

ian at airs dot com wrote:
> ------- Comment #13 from ian at airs dot com  2007-06-30 18:08 -------
> The problem here is that although the stack pointer is not used in the
> function, adjusting it does reserve space on the stack for the local variables
> which are used.  The local variables are accessed via the frame pointer with a
> negative offset.  Deleting the adjustment of the stack pointer is causing that
> the reference to be implicitly invalid.  This test case makes the problem
> obvious via an asm which essentially does a function call which the compiler
> doesn't know about.  If the asm weren't there, though, there would still be a
> difficult to diagnose problem in that an interrupt at the wrong time would
> corrupt the value of the local variables.
>
> One possible approach to this is that DF should note that any reference to a
> local variable via the frame pointer is implicitly a use of the stack pointer. 
> Note that this doesn't necessarily mean a negative offset from the frame
> pointer, although it does in this case.  On processors like the Thumb even
> local variables are accessed as positive offsets from the frame pointer, and
> parameters are accessed by larger positive offsets.  We also need to consider
> whether any asm statement is a use of the stack pointer.  It may be that DF
> should treat an asm statement however it treats a function call with regard to
> uses of the stack pointer.  A non-volatile asm would be a const call, and a
> volatile asm would be an ordinary call.  I'm not completely sure about that,
> but it seems worth considering. 
>
> A simpler approach would be for DCE to simply not remove adjustments to the
> stack pointer.  I believe this would have to be done whether the adjustment was
> frame related or not.  I think the fact that the instruction is frame related
> is probably a red herring here.
>
>
>   
2007-07-02  Kenneth Zadeck <zadeck@naturalbridge.com>

    PR middle-end/32475

    * df-scan.c (df_ref_record): Add ref for stack_ptr whenever
    mem is referenced thru hard_frame_pointer.
    (df_uses_record): Add ref for stack_ptr for asm insns since they
    may implicitly use the stack.

This patch does what iant suggested.  It fixes this pr and bootstraps
and regression tests on x86-64.

Ok for trunk?

Kenny

Index: df-scan.c
===================================================================
--- df-scan.c	(revision 126167)
+++ df-scan.c	(working copy)
@@ -2649,7 +2649,19 @@ df_ref_record (struct df_collection_rec 
 	  endregno = regno + subreg_nregs (reg);
 	}
       else
-	endregno = END_HARD_REGNO (reg);
+	{
+	  endregno = END_HARD_REGNO (reg);
+
+	  /* If we have a mem reference that is relative to the
+	     hard_frame_pointer, add a reference to the stack_pointer.
+	     This keeps the stack pointer alive when there may not be
+	     any other obvious reason.  */
+	  if ((ref_type == DF_REF_REG_MEM_STORE 
+	       || ref_type == DF_REF_REG_MEM_LOAD)
+	      && regno == HARD_FRAME_POINTER_REGNUM)
+	    df_ref_record (collection_rec, regno_reg_rtx[STACK_POINTER_REGNUM],
+			   NULL, bb, insn, ref_type, ref_flags);
+	}
 
       /*  If this is a multiword hardreg, we create some extra
 	  datastructures that will enable us to easily build REG_DEAD
@@ -2955,6 +2967,11 @@ df_uses_record (struct df_collection_rec
 	    for (j = 0; j < ASM_OPERANDS_INPUT_LENGTH (x); j++)
 	      df_uses_record (collection_rec, &ASM_OPERANDS_INPUT (x, j),
 			      DF_REF_REG_USE, bb, insn, flags);
+
+	    /* The stack ptr may be used (honorarily) by an ASM,
+	       especially if the asm makes a function call.  */
+	    df_ref_record (collection_rec, regno_reg_rtx[STACK_POINTER_REGNUM],
+			   NULL, bb, insn, DF_REF_REG_USE, flags);
 	    return;
 	  }
 	break;