Hi DJ,
My concern is more about calling NEXT_INSN on a deleted insn. If
that's guaranteed to be "reliable", I'm OK with it.
So pick whichever solution is more future-proof and go for it :-)
OK, I have gone with the following. I have replaced NEXT_INSN with
next_nonnote_nondebug_insn, so
My concern is more about calling NEXT_INSN on a deleted insn. If
that's guaranteed to be "reliable", I'm OK with it.
Alternately, call NEXT_INSN at the top of the loop, but save the value
until the *next* iteration of the loop, so we can delete the insn and
not have to call NEXT_INSN on it after
Hi DJ,
We have this at the top of the loop, so I don't think it matters:
next = NEXT_INSN (insn);
if (GET_CODE (insn) != INSN)
continue;
Good point.
However, I think an insn will be skipped if we use NEXT. Perhaps we
want PREV? Or the loop might need to be
We have this at the top of the loop, so I don't think it matters:
next = NEXT_INSN (insn);
if (GET_CODE (insn) != INSN)
continue;
However, I think an insn will be skipped if we use NEXT. Perhaps we
want PREV? Or the loop might need to be altered to account for t
Hi DJ,
The delete_insn() function no longer returns the insn after the one
that has been deleted, so gcc/config/mep/mep.c:mep_reorg_regmove() no
longer compiles. The patch below is a simple fix for the problem, but
I was not sure whether it would be better to use
next_nonnote_nondebug_i
