This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Short Displacement Problems.
- From: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Joern Rennecke <joern dot rennecke at superh dot com>, jh at suse dot cz, Joe Buck <Joe dot Buck at synopsys dot com>, kenner at vlsi1 dot ultra dot nyu dot edu, gcc at gcc dot gnu dot org
- Date: Fri, 31 May 2002 18:08:16 +0530
- Subject: RE: Short Displacement Problems.
> Zack Weinberg wrote:
> >
> > One problem with this strategy is that
> > reshuffling stack during reload is expensive because
> >
> > 1. There would be lot of stack variable references that we
> will have to
> > fix up in insn chain while allocating "each" stack slot.
> > The entire logic will increase compilation time.
>
> 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. We could assign memory locations to these with just one
> linear scan over the RTL to replace them with MEM expressions at the
> end.
I agree with you on this.The present stack representation is a
bottleneck and possibly if we decide a better one, it would
beneficial in the long run.
> In fact, if we used this representation from RTL creation time all the
> way to after register allocation, we could make some significant
> improvements to code generation, independent of the
> stack-slot-assignment issue.
>
> Yeah, this would require changes to every machine description and
> every RTL optimizer pass, but it would be worth it.
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 complete before
register
allocation had begun.The reload pass would get rtx's from this
virtual stack.
But finally, all pseudos would not go onto stack.In a post register
allocation pass
this virtual stack is "collapsed" to an actual realistic stack.
Initially, I am thinking to enable this virtual stack for SH only and other
ports might go on to it once I am able to set up a complete infrastructure
in place.
Please let me know if that looks promising enough.
Best Regards,
Naveen Sharma.