Fix PR69752, insn with REG_INC being removed as equiv_init insn

[Jiong Wang]

On 12/02/16 07:43, Jeff Law wrote:
> On 02/11/2016 06:28 PM, Bernd Schmidt wrote:
>> This seems fairly straightforward:
>>
>> (insn 213 455 216 6 (set (reg:SI 266)
>>          (mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4  S4 A32])) 748
>> {*thumb1_movsi_insn}
>>       (expr_list:REG_EQUAL (const_int -1044200508 [0xffffffffc1c2c3c4])
>>          (expr_list:REG_INC (reg/f:SI 267)
>>              (nil))))
>>
>> We don't notice that the SET_SRC has a side effect, record the insn as
>> an equivalencing one, and later remove it because we replaced the reg
>> with the constant everywhere. Thus, the increment doesn't take place.
>>
>> Fixed as follows. Bootstrapped and tested on x86_64-linux. Also compared
>> before/after dumps for the testcase with arm-elf. Ok?
>>
>>
>> Bernd
>>
>> equiv-inc.diff
>>
>>
>>     PR rtl-optimization/69752
>>     * ira.c (update_equiv_regs): When looking for more than a single 
>> SET,
>>     also take other side effects into account.

Will it be better that we don't remove the insn if it has side-effect 
instead of don't record the equiv?

This can offer more equiv for later rtl optimization?



> Also note that the reporter says gcc-4.9 didn't have this problem, so 
> there's a reasonable chance this is a latent regression exposed by 
> codegen changes prior to IRA.
>
>
> OK for the trunk.
>
> Jeff
>