This is the mail archive of the
mailing list for the GCC project.
RE: Allocating some Loop allocno in memory
- From: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: "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>, 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: Mon, 12 Jan 2015 11:33:29 +0000
- Subject: RE: Allocating some Loop allocno in memory
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 126.96.36.199) smtp dot mailfrom=ajit dot kumar dot agarwal at xilinx dot com;
- References: <88eeeae767d342b28335a40637d7e0a1 at BY2FFO11FD048 dot protection dot gbl> <56F1C924-A5BF-4CCE-9811-6E7C76065DE3 at gmail dot com> <d06d3e00fd344c948a4f22a1fd2d4737 at BY2FFO11FD007 dot protection dot gbl> <CAFiYyc0c1QJdjEEWznjbbwk5BZMOHS1vQ9huMY_ihNN18+T9wQ at mail dot gmail dot com>
From: Richard Biener [mailto:firstname.lastname@example.org]
Sent: Monday, January 12, 2015 2:33 PM
To: Ajit Kumar Agarwal
Cc: email@example.com; firstname.lastname@example.org; email@example.com; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: Allocating some Loop allocno in memory
On Sun, Jan 11, 2015 at 4:45 PM, Ajit Kumar Agarwal <firstname.lastname@example.org> wrote:
> -----Original Message-----
> From: Richard Biener [mailto:email@example.com]
> Sent: Sunday, January 11, 2015 8:05 PM
> To: Ajit Kumar Agarwal; firstname.lastname@example.org; email@example.com;
> Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju
> Subject: Re: Allocating some Loop allocno in memory
> On January 11, 2015 5:25:23 AM CET, Ajit Kumar Agarwal <firstname.lastname@example.org> 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
>>>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.
> If the live range covering the loop assigned to memory, and there are
> references inside the Loops then there are chances of spills inside
> the loop which degrades the performance. If live range covering the
> loops and there are no references inside the Loop, then assigning to
> memory make reasonable as there are no references. Since there are no
> references or not touched inside the Loop, there won't be load instruction to restore which are required if there are any references. The store which requires for the def of the Live range will be outside the Loops. This helps in not degrading the performances as there are no load and store required for spill and restore inside the Loops.
> The above heuristics can also be accompanied with heuristics of the
> number of use points in the Live range. Considering both the
> heuristics will lead to better allocation if ever spill at the live
> range split points and there are chances of getting colorable the
> Interference graph without degrading the performance. Also if the Live range is splitted at the Loop boundary then the spill at the split points of loop boundary and registers is assigned to this live range will make it reasonable if there are no references inside the Loops.
>>But if we split the life-range of not used in-loop-body pseudos at the loop boundary the allocator should do the assignment to memory.
>>There is no need to add another heuristic here. Or do you say we don't split the life-range of such pseudos at loop boundary?
In spill_cost calculations we are seeing the function ira_loop_edge_freq triggered with the Live ranges that are live at the exit of the Loop but
are not referenced inside the Loops. We are still considering frequency in the updation of spill cost for such live ranges . We have made a change
not to consider the freq of such live ranges in the updation of spill cost, thus reducing the cost of such live ranges making it a chance to be in
memory giving the conflicting allocno the chances of getting the register. There are chances , the conflicting allocno with respect to loops
which have references and will have more edge on getting the registers.
The changes are made in the following.
Thanks & Regards
> Thanks & Regards
>>Thanks & Regards