RE: Short Displacement Problems.

["Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>]

Hi Everybody,

>From the discussion thread regarding this problem, I 
think

1. Optimizing stack offsets is definitely desirable.Everybody
   would like to have this feature(especially from embedded targets
viewpoint).
   Also desired was that this change should work optimally with
   structs and arrays on stack.

2. The issues raised were only regarding its implementation methods.
   Following were the suggested implementation approaches,

First approach
--------------
> > On May 30, 2002, Zack Weinberg <zack@codesourcery.com> wrote:
> >
> > > Only if we stick with the existing, lame, way of 
> representing stack
> > > slots.  (mem:MODE (plus:P (reg:P sp) (const_int offset))) 
> is a pain to
> > > work with, yes.  Consider (stack:MODE slot) instead -- 
> with slot being
> > > akin to a pseudo-register number, and only one instance 
> of any given
> > > stack RTX.

This approach requires lot of changes. However, if it is worth the effort
and a clean solution, then we can go for it. Following two issues were
highlighted about this approach,

	a)Issue of CSE able expressions while computing offsets after
        register allocation.(partly addresseable by reload_cse)
      b)Loop optimizations.( this will be needed to be addressed in a 
				      post-register allocation optimizations
pass) 

Second Approach
---------------
To minimize changes, I  am thinking of abstracting the stack 
in a slightly different way.
Initially we take the ASSUMPTION that all pseudos would be on to the stack
and pseudos would be placed on the "big virtual stack" based on locality.  
So stack assignment of all psuedos on "virtual stack" is done before
register
allocation had begun.The reload pass would get rtx's from this
virtual stack.
But finally, as all pseudos would not go onto stack, In a post register
allocation pass
this virtual stack is "collapsed" to an actual realistic stack.

Issues (a & b)  mentioned above should be addressed by this approach as
well.
The only advantage might be lesser number of changes.

Also, Does it make sense to integrate this with 
new register allocator branch, if that is going to be the register allocator
some time in the future. 
Please let me know your thoughts on these.

Best Regards,
  Naveen Sharma.