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: Allocation of hotness of data structure with respect to the top of stack.


Vladimir Makarov <vmakarov@redhat.com> writes:
> On 2015-07-05 7:11 AM, Ajit Kumar Agarwal wrote:
> > All:
> >
> > I am wondering allocation of hot data structure closer to the top of the stack increases
> the performance of the application.
> > The data structure are identified as hot and cold data structure and all the data
> structures are sorted in decreasing order of
> > The hotness and the hot data structure will be allocated closer to the top of the stack.
> >
> > The load and store on accessing with respect to allocation of data structure on stack
> will be faster with allocation of hot
> > Data structure closer to the top of the stack.
> >
> > Based on the above the code is generated with respect to load and store with the correct
> offset of the stack allocated on
> > the decreasing order of hotness.
> >
> >
> What can be done for this in RA was already done for LRA and reload
> about seven years ago.  More frequently used slots for spilled pseudos
> are placed closer to the address base (stack pointer or frame pointer).
> It gave considerable code size improvement and nice performance
> improvement on x86/x86-64 as the displacements in 128 range needs less
> memory in x86 insns.  The details can be found in my presentation of IRA
> or LRA on a GCC summit.
> 
> Placement of local arrays and structures are actually done in
> front-end.  I remember the existence of the problem and that somebody
> tried to address it but don't remember the result.  You can try to
> figure it out searching gcc mail archives.

One thing I have seen for MIPS is that we need to switch our frame to grow downwards so
that spill slots end up closer to SP than any potentially large local data structures.
This gives a noticeable code size benefit for compressed ISAs (MIPS16 and microMIPS).

This change has been buried on a list of mine for some time and is trivial to
implement given we already have a macro for it.

Matthew


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