This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Short Displacement Problems.


> 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 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.

Honza
> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]