------- Comment #21 from zadeck at naturalbridge dot com 2007-07-02 14:12
-------
Subject: Re: [4.3 Regression] function with asm()
does not setup stack frame
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 <[EMAIL PROTECTED]>
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;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
