[aarch64-port-dev ] RFR: 8172881: AArch64: assertion failure: the int pressure is incorrect

[Yang Zhang]

Hi Andrew

I have analysed the reason why R27 is allocated as dst register in
this failed case. Please check the analysis as follows:


There are 6 nodes result in that R27 is used:
Node 16: MachProj, liverange 1
Node 17: MachProj, liverange 2
Node 90: get_and_setI, liverange 11
Node 96: tlsloadP, liverange 12
Node 112: MachProj, liverange 22
Node 181: MachProj, liverange 23

(i)In the first call of build_ifg_physical, These nodes get the
following register range (lrg is used to describe node.):
1: [R31,R31_H]
2: [rS206,rS207]
11: [R10,R11,R12,R13,R14,R15,R16,R17,R18,R0,R1,R2,R3,R4,R5,R6,R7,R19,R20,R21,R22,R23,R24,R25,R26,R27,R28,R29,R30]
12:[R28,R28_H]
22:[R0,R0_H]
23:[R10-R18_H,R1-R26_H,V16-RFLAGS].
Note: 23 is a fat projection node which will occupy all the unused
non-specical register.

(ii)In the second call of build_ifg_physical, the error happens in B9
of IdealGraph.

23 is processed firstly. It's a fat projection node (one of conditions
setting _is_bound flag) so that
remove_bound_register_from_interfering_live_ranges is called. In this
function the other 5 nodes(1, 2, 11, 12, 22) are not allowed to use
the register range of 23. The updated register ranges are as follows:

23: [R10-R18_H,R1-R26_H,V16-RFLAGS]
1:  [R31,R31_H]
2:  [rS206,rS207]
11:[R0,R27,R28,R29,R30] ------------- the range is limited.
12:[R28,R28_H]
22:[R0,R0_H]

22 is processed secondly. It uses only one register (another one of
conditions setting _is_bound flag) and
remove_bound_register_from_interfering_live_ranges is called. In this
function the other 4 nodes(1, 2, 11, 12) are not allowed to use the
register range of 22.The updated register ranges are as follows:

22:[R0,R0_H]
1:  [R31,R31_H]
2:  [rS206,rS207]
11:[R27,R28,R29,R30] ------------- the range is limited.
12:[R28,R28_H]

The assembly has proved that R27 is allocated for get_and_setI. Then
the assertion of int_pressure fails.

(iii) With the patch, the process of register is as follows:

First call of build_ifg_physical, These nodes get the following
register range (lrg is used to describe node.):
1: [R31,R31_H]
2:[rS206,rS207]
11:[R10,R11,R12,R13,R14,R15,R16,R17,R18,R0,R1,R2,R3,R4,R5,R6,R7,R19,R20,R21,R22,R23,R24,R25,R26]
12:[R28,R28_H]
22:[R0,R0_H]
23:[R10-R18_H,R1-R26_H,V16-RFLAGS].

Second call of build_ifg_physical:
23 [R10-R18_H,R1-R26_H,V16-RFLAGS]
1: [R31,R31_H]
2:[rS206,rS207]
11:[R0] ------------- the range is limited.
12:[R28,R28_H]
22:[R0,R0_H]


22 [R0,R0_H]
1: [R31,R31_H]
2:[rS206,rS207]
11:[] ------------- the node is spilled.
12:[R28,R28_H]


I will check other instructions again to see if there is any other
instruction which uses special register as dst register.


Regards
Yang


On 24 January 2017 at 10:47, Ningsheng Jian <ningsheng.jian at linaro.org> wrote:
> On 23 January 2017 at 18:57, Andrew Haley <aph at redhat.com> wrote:
>> On 23/01/17 10:41, Ningsheng Jian wrote:
>>> On 23 January 2017 at 18:13, Andrew Haley <aph at redhat.com> wrote:
>>>> On 23/01/17 09:02, Ningsheng Jian wrote:
>>>>
>>>> I think it would be safest at this stage to change both arguments to
>>>> iRegLNoSp.  Please try that.  It doesn't make any sense for either
>>>> argument to be in a special-purpose register.
>>>
>>> The newv is not a def. I think the node which defines it should have
>>> already taken care of it.
>>
>> True.  I looked at the code, and I get it now.  It's all rather
>> confusing: I've just had a look at the way atomic_xchg is defined, and
>> I see that it uses rscratch2 if prev and newv are allocated the same
>> register.  It's all rather ugly, but it's OK.
>>
>>> But yes, both regs should be non-special
>>> registers. I agree it would be safer to mark them both as non special
>>> purpose registers.
>>
>> I don't think it matters.  I'm happy to go with your original patch
>> if you prefer.
>
> OK. Original one looks good to me. Thanks!
>
> Regards,
> Ningsheng