On 27 November 2015 at 12:26, Ramana Radhakrishnan
<ramana.radhakrish...@foss.arm.com> wrote:
>
>
> On 27/11/15 09:40, Renlin Li wrote:
>> 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.
>
> Thanks for digging further and trying to figure out what the solution was. I
> can't think of a less risky fix than what you have proposed, thus Ok if no
> regressions.
>
>
Hi,
I have noticed regressions after this commit to the 4.9 branch:
Passed now fails [PASS => FAIL]:
gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions (test for excess errors)
gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer
-funroll-loops (test for excess errors)
Pass disappears [PASS => ]:
gcc.c-torture/execute/scal-to-vec1.c compilation, -O2
gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto
-fno-use-linker-plugin -flto-partition=none
gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
Fail appears [ => FAIL]:
gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions (internal compiler error)
gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer
-funroll-loops (internal compiler error)
gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 (internal
compiler error)
gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto
-fno-use-linker-plugin -flto-partition=none (internal compiler error)
gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
See the red links in
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/gcc-4_9-branch/231177/report-build-info.html
Christophe.
> regards
> Ramana
>
>
>
>
>
>>
>> Regards,
>>
>> Renlin Li
>>
>>
>>
