I didn't actually bisect this, but I strongly suspect this relates to
the recent set INSN_CODE before calling insn_cost.
An obscure corner case I didn't even know existed. Inside combine we
can create nop moves which look something like (set (pc) (pc)). That
would have triggered an early out in msp430_insn_cost. After the
combine change those insns use NOOP_MOVE_INSN_CODE via special hackery
in combine rather than the -1 for an unrecognized insn.
So rather than early exit from msp430_insn_code, we try to call
get_attr_length of that noop move which of course fails and triggers all
kinds of testsuite regressions.
While I considered checking earlier in the call stack, msp430 seems to
be the only port affected, so I put it down in there. Built and
regression tested where it fixes the recent regressions and causes no
new regressions. Pushing to the trunk.
jeff
diff --git a/gcc/config/msp430/msp430.cc b/gcc/config/msp430/msp430.cc
index 671b95029d21..5b3e447881af 100644
--- a/gcc/config/msp430/msp430.cc
+++ b/gcc/config/msp430/msp430.cc
@@ -1657,6 +1657,9 @@ msp430_insn_cost (rtx_insn *insn, bool speed
ATTRIBUTE_UNUSED)
if (recog_memoized (insn) < 0)
return 0;
+ if (INSN_CODE (insn) == NOOP_MOVE_INSN_CODE)
+ return 0;
+
/* The returned cost must be relative to COSTS_N_INSNS (1). An insn with a
length of 2 bytes is the smallest possible size and so must be equivalent
to COSTS_N_INSNS (1). */
