This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Short Displacement Problems.
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- Cc: 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 09:40:53 -0700
- Subject: Re: Short Displacement Problems.
- References: <E04CF3F88ACBD5119EFE00508BBB212102DB5065@exch-01.noida.hcltech.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
end.
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.
zw