This is the mail archive of the
mailing list for the GCC project.
Re: Short Displacement Problems.
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- Cc: 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: Wed, 29 May 2002 14:58:02 +0100
- Subject: Re: Short Displacement Problems.
- Organization: SuperH UK Ltd.
- References: <E04CF3F88ACBD5119EFE00508BBB212102DB444C@exch-01.noida.hcltech.com>
"Naveen Sharma, Noida" wrote:
> POSSIBLE SOLUTIONS.
> 1. We introduce a pass for achieving objectives #1 and #2.
> For addressing the locality issue we do the following
> a. Create an access sequence of data items in the insn stream.
> This would give information of usage and frequency of reference
> of variables e.g. for code like
> Sequence in which they variables are accessed is "a d c d e f"
> b. Then we construct an Access Graph telling number of times
> two ( or greater) variables are accessed adjacently (or nearby)
> e.g. in access graph constructed from above sequence we
> would have an edge between <a, d> with frequency they occur adjacent.
> Ideally all adjacent references should be at a SHORT displacement.
> c. From this information, we can determine placement of variables on the
> stack to
> minimize large displacements.(we would be spanning this graph to
> accesses that occur nearby)
> 2. A second option is to possibly view this in spirit similar
> to register allocation. The problem is to allocate M fast access slots
> (within N bit displacement window with respect to a base register)
> among total references with respect to that base register.
> Variables live at the same time must be allocated at different
> If it is possible to allocate them in fast access window, we do so;
> otherwise the variable has to be allocated on slow access window.
> (Technically spilled to slow access window) and spill would mean
> addition of extra code to access the desired variable.
> An obvious problem ( as I mentioned in my previous mail)
> I could see is that most of stack allocations are called from reload.
> While stack offset assignments would be most beneficial before register
> allocation, the picture of the stack isn't clear untill reload.
> I want that register allocation should benefit from offset assignments.
> If I do stack offset assignment after register allocation,
> I might get reduction in code size but that would be not be as good
> as it won't reduce register pressure during register allocation/reload.
> Thoughts and ideas ??
In general, the most important subproblem is to find the best stack slots for
register spills. -O2 is notoriously bad at this, because the registers that
are spilled last get the largest offsets. -O2 -fomit-frame-pointer, OTOH,
gives the last stilled registers the smallest offset.
If you want to get any better than that, your optimization has to run inside
of or alongside to or instead of reload.
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330