[PATCH] Fix PR 51505

Andrey Belevantsev abel@ispras.ru
Mon Jan 30 08:44:00 GMT 2012


On 30.01.2012 11:38, Paolo Bonzini wrote:
> On 01/29/2012 04:09 PM, Eric Botcazou wrote:
>>>> As discussed in Bugzilla, this is the patch implementing Paolo's
>>>> suggestion of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes. The
>>>> code assumes there is at most one such note per insn.
>>>
>>> That's wrong though and wreaks havoc during reload, e.g.:
>>>
>>> (insn 169 60 62 4 (set (reg:TF 158)
>>> (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
>>> (const_int -16 [0xfffffffffffffff0])) [3 S16 A64]))
>>> 960513-1.c:13 97 {*movtf_insn_sp32}
>>> (expr_list:REG_EQUIV (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
>>> (const_int -16 [0xfffffffffffffff0])) [3 S16 A64])
>>> (expr_list:REG_EQUAL (mult:TF (reg/v:TF 110 [ d ])
>>> (reg:TF 154))
>>> (nil))))
>>>
>>> because the REG_EQUIV note disappears behind reload's back and it isn't
>>> prepared for that. This is the cause of the following regression on SPARC:
>>>
>>> FAIL: gcc.c-torture/execute/960513-1.c execution, -Os
>>
>> As well as:
>>
>> FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2
>> FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O3 -fomit-frame-pointer
>> FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O3 -g
>> FAIL: gcc.c-torture/execute/stdarg-2.c execution, -Os
>> FAIL: gcc.c-torture/execute/stdarg-2.c
>> execution, -O2 -flto -flto-partition=none
>> FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2 -flto
>>
>> for the exact same reason.
>
> Does this help?

That would fix the problem of multiple notes per insn (as we wanted to do 
initially), but I didn't understand whether this is the real problem or the 
problem is the reload not happy with disappearing notes.  Also I can't 
reproduce it with a cross to sparc64-linux -- when I put a breakpoint on 
the code removing the notes, I find only similarly looking insn 148 which 
gets removed from the df_analyze call at the start of IRA.  Though I see 
the fail from SPARC test results on the ML, so I guess I'm missing something...

Andrey

>
> Paolo
>



More information about the Gcc-patches mailing list