This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [2/9] Add a REG_NREGS macro
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 19 May 2015 07:51:51 +0100
- Subject: Re: [2/9] Add a REG_NREGS macro
- Authentication-results: sourceware.org; auth=none
- References: <87oalhu59s dot fsf at e105548-lin dot cambridge dot arm dot com> <87fv6tu52q dot fsf at e105548-lin dot cambridge dot arm dot com> <555A4AC7 dot 4040005 at redhat dot com>
Jeff Law <law@redhat.com> writes:
> On 05/18/2015 12:13 PM, Richard Sandiford wrote:
>> This patch adds a REG_NREGS macro that by the end of the series
>> will simply be an rtx field access. The definition in this patch
>> is just a placeholder (and so I haven't tried to avoid the double
>> evaluation of the parameter).
>>
>> The diff has extra context because in most cases it makes it obvious
>> that we really are looking at hard_regno_nregs[REGNO (x)][GET_MODE (x)]
>> for some rtx x. There are a couple of sites where it's more indirect
>> though.
>>
>>
>> gcc/
>> * rtl.h (REG_NREGS): New macro
>> * alias.c (record_set): Use it.
>> * cfgcleanup.c (mark_effect): Likewise.
>> * combine.c (likely_spilled_retval_1): Likewise.
>> (likely_spilled_retval_p, can_change_dest_mode): Likewise.
>> (move_deaths, distribute_notes): Likewise.
>> * cselib.c (cselib_record_set): Likewise.
>> * df-problems.c (df_simulate_one_insn_forwards): Likewise.
>> * df-scan.c (df_mark_reg): Likewise.
>> * dse.c (look_for_hardregs): Likewise.
>> * dwarf2out.c (reg_loc_descriptor): Likewise.
>> (multiple_reg_loc_descriptor): Likewise.
>> * expr.c (write_complex_part, read_complex_part): Likewise.
>> (emit_move_complex): Likewise.
>> * haifa-sched.c (setup_ref_regs): Likewise.
>> * ira-lives.c (mark_hard_reg_live): Likewise.
>> * lra.c (lra_set_insn_recog_data): Likewise.
>> * mode-switching.c (create_pre_exit): Likewise.
>> * postreload.c (reload_combine_recognize_const_pattern): Likewise.
>> (reload_combine_recognize_pattern): Likewise.
>> (reload_combine_note_use, move2add_record_mode): Likewise.
>> (reload_cse_move2add): Likewise.
>> * reg-stack.c (subst_stack_regs_pat): Likewise.
>> * regcprop.c (kill_value, copy_value): Likewise.
>> (copyprop_hardreg_forward_1): Likewise.
>> * regrename.c (verify_reg_in_set, scan_rtx_reg): Likewise.
>> (build_def_use): Likewise.
>> * sched-deps.c (mark_insn_reg_birth, mark_reg_death): Likewise.
>> (deps_analyze_insn): Likewise.
>> * sched-rgn.c (check_live_1, update_live_1): Likewise.
>> * sel-sched.c (count_occurrences_equiv): Likewise.
>> * valtrack.c (dead_debug_insert_temp): Likewise.
>>
> OK.
>
> Makes me wonder if we want to poison hard_regno_nregs in some way to
> avoid folks re-introducing this stuff in the future... Your call if you
> want to tackle that as a follow-up.
The problem is that many uses of hard_regno_nregs aren't about
existing REGs. E.g. the register allocators need to know how many
registers something would occupy before allocating it, so they (rightly)
make heavy use of it with a calculated regno and/or mode.
Agree that people will probably do things the old way out of habit.
Maybe it's just something I should grep for occasionally...
Thanks,
Richard