> Am 16.10.2018 um 19:35 schrieb Jeff Law <l...@redhat.com>:
> 
> On 10/16/18 10:10 AM, Ilya Leoshkevich wrote:
>> 
>> So I plan to keep using lra_get_insn_recog_data (), but with an extra
>> INSN_P () check.
> Seems reasonable.   Though note that INSN_P will accept DEBUG_INSNs.
> That may be OK -- those routines have some code for handling
> DEBUG_INSNs, but I didn't audit those paths carefully.
The logic for handling DEBUG_INSNs in lra_set_insn_recog_data () is
fairly short, so they seem to be fully supported:

  if (DEBUG_INSN_P (insn))
    {
      data->dup_loc = NULL;
      data->arg_hard_regs = NULL;
      data->preferred_alternatives = ALL_ALTERNATIVES;
      if (DEBUG_BIND_INSN_P (insn))
        {
          data->insn_static_data = &debug_bind_static_data;
          data->operand_loc = XNEWVEC (rtx *, 1);
          data->operand_loc[0] = &INSN_VAR_LOCATION_LOC (insn);
        }
      else if (DEBUG_MARKER_INSN_P (insn))
        {
          data->insn_static_data = &debug_marker_static_data;
          data->operand_loc = NULL;
        }
      return data;
    }

I browsed a random RTL dump and found that some DEBUG_INSNs may refer to
hard regs:

    (debug_insn (var_location:SI dz (reg/v:SI 0)))

So I guess I have to use INSN_P ().  I will push the v2 once regtest is
finished.

Reply via email to