| Message ID | AM4PR0701MB216244D6F83C50AF652AC640E4CD0@AM4PR0701MB2162.eurprd07.prod.outlook.com |
|---|---|
| State | New |
| Headers | show |
On 09/26/2016 09:55 AM, Bernd Edlinger wrote: > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? > > > Yes. Thank you for working on the problem, Bernd.
2016-09-26 Bernd Edlinger <bernd.edlinger@hotmail.de> PR rlt-optimization/77714 * lra-eliminations.c (eliminate_regs_in_insn): Avoid alias on REG_EQUAL note. Index: gcc/lra-eliminations.c =================================================================== --- gcc/lra-eliminations.c (revision 240471) +++ gcc/lra-eliminations.c (working copy) @@ -981,7 +981,7 @@ eliminate_regs_in_insn (rtx_insn *insn, bool repla } lra_update_insn_recog_data (insn); /* Add offset note for future updates. */ - add_reg_note (insn, REG_EQUAL, src); + add_reg_note (insn, REG_EQUAL, copy_rtx (src)); return; } }
Hi! This fixes another fallout of the recent change in the pattern matching, which makes LRA choose a different alternative for this insn: (insn 48 21 23 3 (set (reg/f:SI 102 sfp) (reg/f:SI 7 r7)) 808 {*thumb1_movsi_insn} (nil)) This is replaced as a special case to set((sfp)(r7-sfp_fp_elim_off)). LRA choses thumb1_addsi3, alt 2 instead of alt 1, because sfp != r7, while elimination of sfp->r7. Unfortunately the insn gets a REG_EQUAL note temporarily attached, which is spoiled by the elimination, so the reg-note is no longer usable, and the instruction gets deleted in the final transformation. So, as it looks like, this was a latent bug, as it is not OK to have an alias on any RTX, except on a simple REG. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd.