This is the mail archive of the
mailing list for the GCC project.
RE: Allocation of hotness of data structure with respect to the top of stack.
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>, Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>, "law at redhat dot com" <law at redhat dot com>, "Richard Biener" <richard dot guenther at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: Vinod Kathail <vinodk at xilinx dot com>, Shail Aditya Gupta <shailadi at xilinx dot com>, Vidhumouli Hunsigida <vidhum at xilinx dot com>, "Nagaraju Mekala" <nmekala at xilinx dot com>
- Date: Fri, 10 Jul 2015 07:17:23 +0000
- Subject: RE: Allocation of hotness of data structure with respect to the top of stack.
- Authentication-results: sourceware.org; auth=none
- References: <37378DC5BCD0EE48BA4B082E0B55DFAA41F41485 at XAP-PVEXMBX02 dot xlnx dot xilinx dot com> <559F1995 dot 9070103 at redhat dot com>
Vladimir Makarov <email@example.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.