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.




> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Alexandre Oliva
> Sent: Friday, May 31, 2002 10:14 AM
> To: Zack Weinberg
> Cc: Naveen Sharma, Noida; Joern Rennecke; law@redhat.com;
> bernds@redhat.com; gniibe@m17n.org; Richard Henderson; gcc@gcc.gnu.org
> Subject: Re: Short Displacement Problems.
>
>
> On May 30, 2002, Zack Weinberg <zack@codesourcery.com> wrote:
>
> > 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.
>
> How is this different from plain pseudos?  At some point, we have to
> turn them into (mem (plus (reg sp) (const_int offset))), and reload is
> probably the best point.  It would be nice to defer the computation of
> the offset, but optimizing that can be very tricky if you consider
> that, by changing the location of a very commonly used pseudo to a
> stack slot with a smaller offset, and moving whatever was in that
> location to a stack slot with a larger offset, you end up needing more
> registers to hold the address, so you have to spill them, but you
> can't use yet another register to hold the spill address, so you
> lose.  This is just a simplified view of the complications.

If we assume that there are some targets which can efficiently encode small
offsets, might it not make sense to have the spill logic attempt to optimize
the most frequent references (or some other cost-weighted function) to the
smallest offsets, and then on a target-specific basis, run a second pass if
and only if at least one offset was encountered which is above some
target-defined maximum? In this case, the register allocator might need to
dedicate an additional register in order to avoid the spill difficulties
outlined above, before making the second pass. Thus, a second pass is only
required for larger, more complex programs, and is invoked in a
machine-dependent set of circumstances.


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