This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: Stack Reorganization Patch
- From: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- To: jbuck at synopsys dot com
- Cc: gcc-patches at gcc dot gnu dot org, Zack Weinberg <zack at codesourcery dot com>, Jan Hubicka <jh at suse dot cz>, Joern Rennecke <joern dot rennecke at superh dot com>, Alexandre Oliva <aoliva at redhat dot com>, Gary Funck <gary at intrepid dot com>
- Date: Sun, 5 Jan 2003 15:24:16 +0530
- Subject: RE: Stack Reorganization Patch
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.