[RFC] Add middle end hook for stack red zone size

[Joern Rennecke]

Quoting Jiangning Liu <jiangning.liu@arm.com>:

> Hi,
>
> One month ago, I sent out this RFC to *gcc-patches* mail list, but I  
>  didn't receive any response yet. So I'm forwarding this mail to   
> *gcc* mail list. Can anybody here really give feedback to me?

Well, I couldn't approve any patch, but I can point out some issues
with your patch.

First, it's missing a ChangeLog, and you don't state how you have tested it.
And regarding the code in sched_analyze_1, I think you'll get false
positives with alloca, and false negatives when registers are involved
to compute offsets or to restore the stack pointer from.

FWIW, I think generally blunt scheduling barriers should be avoided, and
instead the dependencies made visible to the scheduler.
E.g., I've been working with another architecture with a redzone, where at
-fno-omit-frame-pointer, the prologue can put pretend_args into the redzone,
then after stack adjustment and frame allocation, these arguments are
accessed via the frame pointer.

With the attached patchlet, alias analysis works for this situation too, so
no blunt scheduling block is required.

Likewise, with stack adjustments, they should not affect scheduling in
general, but be considered to clobber the part of the frame that is
being exposed to interrupt writes either before or after the adjustment.
At the moment, each port that wants to have such selective scheduling
blockages has to define a stack_adjust pattern with a memory clobber  
in a parallel, with a memref that shows the high water mark of possible
interrupt stack writes.
Prima facia it would seem convenient if you only had to tell the middle-end
about the redzone size, and it could figure out the implicit clobbers when
the stack is changed.  However, when a big stack adjustment is being made,
or the stack is realigned, or restored from the frame pointer / another
register where it was saved due to realignment, the adjustment is not
so obvious.  I'm not sure if you can actually create an robust interface
that's simpler to use than putting the right memory clobber in the stack
adjust pattern.  Note also that the redzone size can vary from function
to function depending on ABI-altering attributes, in particular for interrupt
functions, which can also have different incoming and outgoing redzone
sizes.  Plus, you can have an NMI / reset handler which can use the stack
like an ordinary address register.
-------------- next part --------------
2009-09-23  Joern Rennecke <joern.rennecke@embecosm.com>

	* alias.c (base_alias_check): Allow for aliases between stack-
	and frame-pointer referenced memory.

Index: alias.c
===================================================================
--- alias.c	(revision 1646)
+++ alias.c	(revision 1647)
@@ -1751,6 +1751,17 @@ base_alias_check (rtx x, rtx y, enum mac
   if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
     return 0;
 
+  /* If both are stack references, one via the stack pointer, the other via
+     the frame pointer, there can be an alias.
+     E.g.: gcc.c-torture/execute/20041113-1.c -O3 -g  */
+  if (GET_CODE (x_base) == ADDRESS
+      && (XEXP (x_base, 0) == stack_pointer_rtx
+	  || XEXP (x_base, 0) == hard_frame_pointer_rtx)
+      && GET_CODE (y_base) == ADDRESS
+      && (XEXP (y_base, 0) == stack_pointer_rtx
+	  || XEXP (y_base, 0) == hard_frame_pointer_rtx))
+    return 1;
+
   /* If one address is a stack reference there can be no alias:
      stack references using different base registers do not alias,
      a stack reference can not alias a parameter, and a stack reference