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
