[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Likely just latent before.  The ICE is because modulo-sched.c in
      for (i_reg_move = 0; i_reg_move < nreg_moves; i_reg_move++)
        {
          ps_reg_move_info *move = ps_reg_move (ps, first_move + i_reg_move);

          move->def = i_reg_move > 0 ? first_move + i_reg_move - 1 : i;
          move->uses = sbitmap_alloc (first_move + nreg_moves);
          move->old_reg = old_reg;
          move->new_reg = gen_reg_rtx (GET_MODE (prev_reg));
          move->num_consecutive_stages = distances[0] && distances[1] ? 2 : 1;
          move->insn = gen_move_insn (move->new_reg, copy_rtx (prev_reg));
          bitmap_clear (move->uses);

          prev_reg = move->new_reg;
        }
creates a move instruction from the ca register but rs6000 doesn't support such
a move, and apparently nothing attempts to recog that instruction and bail if
it is non-existent (or if gen_move_insn emits more than one instruction).
I think e.g. insn_latency can be only called on successfully recognized
instructions...