This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More methods of reducing the register pressure

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]