stack height reduction in tree-SSA

[Dale Johannesen]

On Sep 1, 2004, at 9:49 AM, Jeffrey A Law wrote:
> We've discussed various means of trying to tackle the problem of
> sharing stack slots to mitigate the stack space problems.  If
> someone is interested in tackling this problem, I'd suggest
> they ping Richard Henderson who seemed to have the best handle
> on a potential solution when we last discussed it as a group
> a few months ago.

One thing to bear in mind is that it is *not* always beneficial to 
reduce
stack space as much as possible, because this inhibits scheduling.
For example (there is a similar case in SPEC):

int i; double a[100];
for (i=0; i<100; i+=4)
{
   a[i] = i*i*i;
   a[i+1] = (i+1)*(i+1)*(i+1);
   a[i+2] = (i+2)*(i+2)*(i+2);
   a[i+3] = (i+3)*(i+3)*(i+3);
}

Several targets require going through a stack slot to do int->double 
conversion.
If you use a single stack slot, which is possible, you're forced to do
store-load-store-load-store-load-store-load.  You may be better off 
using 4
separate slots, as the stores and loads can be scheduled better.
(I am sure this is the case on ppc).  So please do not solve the more
common problem in a way that makes it impossible to do the right thing
here.

Even sharing space for objects whose live ranges don't overlap can lose 
if it
interferes with the several optimizations that can increase live range,
I believe, e.g. invariant hoisting, interblock scheduling....tree-ssa 
seems to
be way too early to be doing this.  Right before reload is more like it 
IMO.