This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR67383][ARM][4.9]Backport of "Allow any register for DImode values in Thumb2"
- From: Renlin Li <renlin dot li at arm dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, vmakarov at redhat dot com, Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- Date: Fri, 27 Nov 2015 09:40:01 +0000
- Subject: Re: [PR67383][ARM][4.9]Backport of "Allow any register for DImode values in Thumb2"
- Authentication-results: sourceware.org; auth=none
- References: <561FB1B4 dot 3060103 at arm dot com> <5620D6F3 dot 102 at foss dot arm dot com> <5621017F dot 5030604 at arm dot com>
Hi Ramana,
On 16/10/15 14:54, Renlin Li wrote:
The command line implies we remove r7 (frame pointer in Thumb2 -
historical accident, fno-omit-frame-pointer), r9 (ffixed-r9), r10
(-mpic-register) which
leaves us with:
* r0, r1
* r2, r3
* r4, r5
as the only free registers available for DImode values for the whole
compilation.
We then have r0, r1 and r2 live across the insn which means that
there are no free registers to handle DImode values
under the constraints provided unless LRA / reload can spill the
argument registers which it doesn't seem to be able to do
in this particular testcase. Vlad, is that correct ?
According to the logic, conflict hard register are excluded from spill
candidate. That's why, in this case, r0, r1, r2 cannot be used.
In the test case, there are code structure like this.
uint64_t callee (int a, int b, int c, int d);
uint64_t caller (int a, int b, int c, int d)
{
uint64_t res;
/*
single BB contains complicated data processing which requires register pair
*/
res = callee (tmp, b ,c, d);
return res;
}
CES pass in this case will extend the hard register live range across
the whole BB until the callee. In this case, r1, r2, r3 are excluded
from allocatable registers.
There are places in CES which prevents extending the hard register's
live range, for example for hard register which fullfil
small_register_classes_for_mode_p(), class_likely_spilled_p(). However,
argument registers belong to neither of them.
I tried to stop CES from extending argument registers live range.
However, later, scheduler jumps in and re-orders the instruction to
reduce the pseudo register pressure, which in effect extend the argument
register live again.
Regards,
Renlin Li