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