This is the mail archive of the
mailing list for the GCC project.
Re: IRA : Changes in the cost of putting allocno into memory.
- From: Jeff Law <law at redhat 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>, "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: Mon, 12 Jan 2015 12:25:08 -0700
- Subject: Re: IRA : Changes in the cost of putting allocno into memory.
- Authentication-results: sourceware.org; auth=none
- References: <66840d5e338f445690654fd92fe29dcf at BN1AFFO11FD043 dot protection dot gbl>
On 01/08/15 04:00, Ajit Kumar Agarwal wrote:
There's a lot of similarities between this and one aspect of Morgan's
register pressure reduction schemes. I believe he refers to objects of
this nature as transparent across the loop (value is live across the
loop, but neither set nor referenced in the loop -- ie, it's just
holding a resource across the loop).
We have made the changes in the ira-color.c in ira_loop_edge_freq and move_spill_restore. The main motivation
behind the change is to reduce the memory instruction with respect to the Loops. The changes are done to not to
consider the back edge frequency if there are no references of the allocno inside the loop even though the allocno
are live out at the exit of the Loop and Live In at the entry of the Loop. This will reduce the calculation of the cost of
putting allocno into memory. If we reduce the cost of putting allocno into memory, then there are chances of getting
color in the simplification phase of the gcc IRA register allocator. Enabling this, there are chances of putting the allocno
in the register and the splitting phase will split the live range across the Loop boundary. This will beneficial with respect
to reducing memory instruction inside the Loop. Other changes is done to enable some of the allocno to allocate in
memory if the cost is less than equal to zero.
This is the first phase of the change in the IRA core register module, I would like to get your feedbacks on this change
based on this the actual patch is sent. The changes are accompanied with the patch created for the change which will
be easier for you to review the change.
We have tested the changes for Microblaze target for MIBENCH and EEMBC benchmarks and there are no degradation
in the Geomean and some of the Mibench and EEMBC benchmarks is benefitted with this change.
Please review the changes and let me know your feedbacks and other steps needs to be done to incorporate the
changes in the Upstream". We would like to get this change for Microblaze, Please also let us know if the changes are
required to be enabled with any switch flag.
If a loop has high register pressure, then homing these kind of objects
in memory across the loop will reduce the register pressure in the loop
and presumably allow some other objects with more value to live in a
register inside the loop. Of course, if there is little pressure in the
loop, then homing to memory is a waste.
Your approach of ignoring backedge frequency for cost calculation of
these objects is interesting in that it tries to capture the benefits of
Morgan-esque pressure reduction without regressing in cases where the
pressure is not high.
If you've got data which does this does not regress on a more mainstream
target and that it bootstrapps and regression tests on a mainstream
target (x86_64 is by far the most popular), then I'd seriously consider