This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Allocation of hotness of data structure with respect to the top of stack.
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>, "vmakarov at redhat dot com" <vmakarov 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>, 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>, Erik Varga <erik dot varga256 at gmail dot com>
- Date: Tue, 7 Jul 2015 20:36:38 +0900
- 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> <559ADBAF dot 3070204 at redhat dot com>
On 07 Jul 2015, at 04:49, Jeff Law <law@redhat.com> wrote:
> On 07/05/2015 05: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.
> You might want to look at this paper from an old gcc summit conference. Basically they were trying to reorder stack slots to minimize offsets in reg+d addressing for hte SH port. It should touch on a number of common issues/goals.
>
>
> ftp://gcc.gnu.org/pub/gcc/summit/2003/Optimal%20Stack%20Slot%20Assignment.pdf
>
>
> I can't recall if they ever tried to submit that work for inclusion.
Ah, inverse-AMS so to say :)
It might be interesting to combine forward and inverse AMS. In the current AMS GSoC work we're hitting some cases which need mem access reordering in order to pick cheaper address modes. It's not there yet, but if it knows how to reorder mem accesses in the insn stream it could probably be extended to try reordering memory layout of variables.
Cheers,
Oleg