> 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.