RE: Stack Reorganization Patch

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

Hi,

> On Wed, Jan 01, 2003 at 08:08:51PM +0530, Naveen Sharma, Noida wrote:
> > Some time back we had a discussion on layout of locals
> > on stack at (http://gcc.gnu.org/ml/gcc/2002-05/threads.html#02838).
> > With that in mind, here is a patch which delays assignment of hard 
> > stack slots till after register allocation. It works as follows.
> > 
> > A call to assign_stack_local_1 is intercepted and we return a rtx
> > of the form (mem:mode reg/f/c:Pmode regno) for each 
> requested stack slot
> > instead of normal form (mem:mode (plus:Pmode fp const_int offset)).
> > Note that the special flag /c is used to tell that this is 
> > stack address pseudo. The register allocator should not try to 
> > allocate any hard reg for this because it is already a known 
> > stack slot.After register allocation, we sort the allocated stack 
> > slots by size and number of references and convert it to normal
> > "fp + offset" form. We also have to mark them live at end of 
> > each basic block.
> 
> The concept sounds promising, though you get into areas of 
> the compiler I don't know that well.

The concept, somewhat, already exists in one form in new register
allocator. It regards a psuedo greater than max_normal_pseudo as
a spill location (and a stack slot later on). I have tried to 
extend it right back to rtl generation with slightly different 
semantics.Basic idea that emerged from earlier discussion was
that it is possible to change normal stack-slot form  to something more
abstract and later it would give us more control on how do we assign
hard stack slots. Although this is somewhat fundamental change, I am 
hopeful that the concept should be beneficial in general (and particularly 
targets with short displacements).

> How does this affect the allocation for structs?  It seems 
> that, unless you also want to rewrite the debugger information, 

Yes, Actually I have tried to present correct rtx in DECL information
to final debugger output pass.As I understood, when a rtx is associated 
for an allocated struct which encapsulates its initial offset in frame. 
I update this rtx. 

> and also ensure that the address of a struct doesn't reach other 
> functions, the stack slots for fields in structs have to follow 
> their original alignment.  Right? Of course dead stores can still 
> go away.
> 
> > I  get some improvements in some benchmarks (5-6%)
> > (but unfortunately some regressions too)with this patch 
> > and would like that people have a look at it and It would 
> > be great if it makes a useful feature.
> 
> My quick-and-dirty attempt to apply your patch failed to 
> boot; I probably

Thanks for trying it. I would be glad to fix the problem. If you still 
have the failure message, please let me know it.

> messed something up, but I won't get around to trying again 
> for a while.
> In the meantime, I suggest looking at PR 8967 and seeing how you do on
> that case (it's a case where we generate really bad code,  worse in every
> release).

Thanks for pointing to this PR. I will test it and let you know the 
result.

Best Regards,
  Naveen Sharma.