On 10/17/18 12:14 PM, Ilya Leoshkevich wrote:
> Boostrapped and regtested on x86_64-redhat-linux.
>
> Changes since v1:
>
> * Added the missing INSN_P () check.
> * Rewrote the commit message.
>
> 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-16 Ilya Leoshkevich <i...@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-16 Ilya Leoshkevich <i...@linux.ibm.com>
>
> PR rtl-optimization/87596
> * gcc.target/i386/pr87596.c: New test.
OK.
jeff
