On Sat, Mar 12, 2016 at 09:56:54AM -0500, Vladimir Makarov wrote:
> +2016-03-12 Vladimir Makarov <vmaka...@redhat.com>
> +
> + PR target/69614
> + * lra-constraints.c (delete_move_and_clobber): New.
> + (remove_inheritance_pseudos): Use it.
Thanks for working on this.
> --- lra-constraints.c (revision 234142)
> +++ lra-constraints.c (working copy)
> @@ -5850,6 +5850,24 @@ get_regno (rtx reg)
> return -1;
> }
>
> +/* Delete a move INSN with destination reg DREGNO and a previous
> + clobber insn with the same regno. The inheritance/split code can
> + generate moves with preceding clobber and when we delete such moves
> + we should delete the clobber insn too to keep the correct life
> + info. */
> +static void
> +delete_move_and_clobber (rtx_insn *insn, int dregno)
> +{
> + rtx_insn *prev_insn = PREV_INSN (insn);
> +
> + lra_set_insn_deleted (insn);
> + lra_assert (dregno > 0);
> + if (prev_insn != NULL && NONDEBUG_INSN_P (prev_insn)
> + && GET_CODE (PATTERN (prev_insn)) == CLOBBER
> + && dregno == get_regno (XEXP (PATTERN (prev_insn), 0)))
> + lra_set_insn_deleted (prev_insn);
> +}
I just wonder if this isn't at least a latent -fcompare-debug issue.
Using prev_nondebug_insn (insn) instead of PREV_INSN (insn) would look
safer. If you are sure this is always an insn generated during LRA rather
than preexisting, and there is no chance DEBUG_INSNs could appear in
between, please ignore me.
Jakub
