Re: [PATCH] lra: fix spill_hard_reg_in_range clobber check

[Jeff Law <law at redhat dot com>]

On 10/16/18 3:17 AM, Ilya Leoshkevich wrote:
> Bootstrap and regtest are running on x86_64-redhat-linux.
> 
> Insns in FROM..TO range might not be recognized yet, and their
> corresponding entries in lra_insn_recog_data[] might be NULLs.  In the
> code from PR87596 the problematic insn is merely
> 
>     (note 148 154 68 7 NOTE_INSN_DELETED)
> 
> however I assume that non-note insns may occur as well.  So make sure
> they are recognized before touching their lra_insn_recog_data_t.
> 
> gcc/ChangeLog:
> 
> 2018-10-16  Ilya Leoshkevich  <iii@linux.ibm.com>
> 
> 	PR rtl-optimization/87596
> 	* lra-constraints.c (spill_hard_reg_in_range): Use
> 	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  <iii@linux.ibm.com>
> 
> 	PR rtl-optimization/87596
> 	* gcc.target/i386/pr87596.c: New test.
I think this is just papering over the problem.

AFAICT for something like a deleted note lra_get_insn_recog_data is
going to call lra_set_insn_recog_data.  Given that INSN will be a NOTE I
think icode will end up being -1 and we'll eventually get into this clause:

  if (icode < 0)
    {
      int nop, nalt;
      machine_mode operand_mode[MAX_RECOG_OPERANDS];
      const char *constraints[MAX_RECOG_OPERANDS];

      nop = asm_noperands (PATTERN (insn));

And I don't think we should be trying to extract the PATTERN of a note.

I think you need to either filter out the non-insn thingies in
spill_hard_reg_in_range, or go with your patch plus beefing up the
checks in lra_set_insn_recog_data.

jeff