This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Allocating some Loop allocno in memory
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>,"vmakarov at redhat dot com" <vmakarov at redhat dot com>,"law at redhat dot com" <law at redhat dot com>,"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: Sun, 11 Jan 2015 15:35:01 +0100
- Subject: Re: Allocating some Loop allocno in memory
- Authentication-results: sourceware.org; auth=none
- References: <88eeeae767d342b28335a40637d7e0a1 at BY2FFO11FD048 dot protection dot gbl>
On January 11, 2015 5:25:23 AM CET, Ajit Kumar Agarwal <ajit.kumar.agarwal@xilinx.com> wrote:
>
>I was thinking of some of the opportunities with respect to reducing
>spills inside the Loop. If the Live range(allocno)
>spans through the Loop and Live out at the exit of the Loop and there
>are no references or not being touched upon
>inside the Loop, assign the allocno to the memory. This increase the
>chances of getting the register for other allocno
>which spans through the Loop and have reference inside the Loop if the
>interference graph is not colorable.
>
>Since allocno don't have references inside the Loop there won't be any
>load instructions with respect to restore inside
>the loops. There will be a store instruction with respect to spill
>which will be outside the Loop. This will reduce the
>conflicting edges of some of the allocno increasing the chances of
>making colorable of the Interference graph and
>reduces the spills and restore inside the Loop.
>
>This heuristics looks reasonable. This heuristics goes side by side
>with the Live range splitting across the Loop boundary.
>On top of this heuristics, after the Live range splitting across the
>Loop boundary there interference graph is not colorable
>then we can assign some of the splitted live ranges in the memory
>giving chances of registers for the Live ranges(allocno)
>that spans the Loop and have reference inside the Loop.
>
>We can change the cost of allocno in memory based on the above
>heuristics and take the above factor into consideration
>for the cost calculation.
>
>Thoughts Please?
How can this result in better allocations if you only ever spill at life-range split points? The life-range covering the loop should already be assigned to memory if required.
Richard.
>Thanks & Regards
>Ajit