This is the mail archive of the
mailing list for the GCC project.
Re: Short Displacement Problems.
- From: Jan Hubicka <jh at suse dot cz>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>,Joern Rennecke <joern dot rennecke at superh dot com>, law at redhat dot com,Alexandre Oliva <aoliva at redhat dot com>, bernds at redhat dot com,gniibe at m17n dot org, Richard Henderson <rth at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 30 May 2002 18:56:59 +0200
- Subject: Re: Short Displacement Problems.
- References: <E04CF3F88ACBD5119EFE00508BBB212102DB5065@exch-01.noida.hcltech.com> <20020530164053.GA16702@codesourcery.com>
> On Thu, May 30, 2002 at 01:09:19PM +0530, Naveen Sharma, Noida 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
In my experiments I've been simply using ADRESSOF as kind of "ticket for
stack slot" and it appears to work pretty well up to the reload. Major
problem is that lowering the code may result in CSEable expressions.
> 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.