FROM..TO range might contain NOTE_INSN_DELETED insns, for which the
corresponding entries in lra_insn_recog_data[] are NULLs. Example from
the problematic code from PR87596:
(note 148 154 68 7 NOTE_INSN_DELETED)
lra_insn_recog_data[] is used directly only when the insn in question
is taken from insn_bitmap, which is not the case here. In other
situations lra_get_insn_recog_data () guarded by INSN_P () or other
stricter predicate are used. So we need to do this here as well.
A tiny detail worth noting: I put the INSN_P () check before the
insn_bitmap check, because I believe that insn_bitmap can contain only
real insns anyway.
gcc/ChangeLog:
2018-10-19 Ilya Leoshkevich <iii@linux.ibm.com>
PR rtl-optimization/87596
* lra-constraints.c (spill_hard_reg_in_range): Use INSN_P () +
lra_get_insn_recog_data () instead of lra_insn_recog_data[]
for instructions in FROM..TO range.
gcc/testsuite/ChangeLog:
2018-10-19 Ilya Leoshkevich <iii@linux.ibm.com>
PR rtl-optimization/87596
* gcc.target/i386/pr87596.c: New test.
From-SVN: r265306
