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.


"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
> 
>              c=a+d;
>              f=d+e;
> 
>       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
> maximize
>        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
> locations.
>      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.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330


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