This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: More methods of reducing the register pressure
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx 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, 19 Apr 2015 15:43:33 -0400
- Subject: Re: More methods of reducing the register pressure
- Authentication-results: sourceware.org; auth=none
- References: <5796c43e-1add-48f1-9b1e-63f373eef93f at BL2FFO11OLC007 dot protection dot gbl>
On 19/04/15 11:28 AM, Ajit Kumar Agarwal wrote:
Hello All:
To reduce the register pressure, I am proposing the following methods of reducing the registers.
1. Assigning same registers or sharing same register for the logical registers having the same value.
To determine the logical registers having the same value is the real challenge. Is there is any way in
GCC to determine the logical registers having the same value?
I believe you propose to use GVN for building conflict graphs. I've
tried long ago for old RA and it gave tiny improvement for few SPEC2000
tests but significant compiler slow down.
BTW, LRA uses values (see member val for reg_info) in very local scope
to remove some conflicts. The reason for adding this was specific LRA
transformations for reloading which created unnecessary conflicts in
plenty cases.
2. For the architecture with the self-modifying instructions the DEF-USE will not overlap and can
Do the better register allocator and thus reclaiming the registers when it's no longer used.
Such self-modifying instructions can assign the same registers.
For example:
OP R1 -------------Definition.
... .
... No used.
OP R1,R1 ----------------self-modifying.
..... .
...... Not Used
OP R1, R1 ------------ Self-modifying.
To reduce the registers pressure such cases with self-modifying instructions with the architecture
Support will not overlap as the use is done after it's defined. And also the USE will be after the DEF
Making the life time as not overlap and can assign the same registers.
IRA creates small cost preferences for died input operand/output
operands of the same insn. This preferences are processed by general
technique as other preferences and result in assigning the same hard
register in many cases. It is done taking overall RA picture into account.
IMHO, implementing it as a separate pass would create more harm than
benefits, as it makes pseudo live range longer and in some cases
prohibits live-range splitting (when we use different pseudos) at
natural program points for splitting. I even would say that if insn
contains the same pseudo as input and output we should do register
renaming to create a point for potential live range splitting (and
actually register renaming -fweb in GCC is profitable even for 2-op
insns). If there is a possibility and benefit to use the same hard
register, the preference mentioned above will guide IRA to use the same
hard reg.
Such cases needs to be handled separately for the better register pressure usage.
Thoughts Please?
Thanks & Regards
Ajit