This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [4/9] Add a dedicated rtx union member for REGs


Jeff Law <law@redhat.com> writes:
> On 05/18/2015 12:19 PM, Richard Sandiford wrote:
>> This patch replaces the current REG "i0" format with a dedicated structure,
>> so that we can make use of the extra 32 bits in the "i" field.
>>
>> Of the places that iterate on formats and do something for 'i's,
>> most already handled REGs specially before the format walk and
>> so don't need to check for 'r'.  Otherwise it's mostly just a case
>> of adding dummy 'r' cases in order avoid the default gcc_unreachable ()
>> (in cases where we do the same for 'i').  The main exceptions are the
>> cselib.c and lra-constraints.c changes.
>>
>> final.c:leaf_renumber_regs_insn handled REGs specially but then
>> went on to do a no-op walk of the format.  I just added an early
>> exit instead of an empty 'r' case.
>>
>>
>> gcc/
>> 	* rtl.def (REG): Change format to "r".
>> 	* rtl.h (rtunion): Remove rt_reg.
>> 	(reg_info): New structure.
>> 	(rtx_def): Add reg field to main union.
>> 	(X0REGATTR): Delete.
>> 	(REG_CHECK): New macro.
>> 	(SET_REGNO_RAW, rhs_regno, REG_ATTRS): Use it.
>> 	* rtl.c (rtx_format): Document "r".
>> 	(rtx_code_size): Handle REG specially.
>> 	* gengenrtl.c (special_format): Return true for formats
>> 	that include 'r'.
>> 	* gengtype.c (adjust_field_rtx_def): Handle 'r' fields.
>> 	Deal with REG_ATTRS after the field loop.
>> 	* emit-rtl.c (gen_raw_REG): Call rtx_alloc_stat directly.
>> 	* expmed.c (init_expmed): Call gen_raw_REG instead of
>> 	gen_rtx_raw_REG.
>> 	* expr.c (init_expr_target): Likewise.
>> 	* regcprop.c (maybe_mode_change): Likewise.
>> 	* varasm.c (make_decl_rtl): Likewise.
>> 	* final.c (leaf_renumber_regs_insn): Return early after
>> 	handling REGs.
>> 	* genemit.c (gen_exp): Handle 'r' fields.
>> 	* genpeep.c (match_rtx): Likewise.
>> 	* gensupport.c (subst_pattern_match): Likewise.
>> 	(get_alternatives_number, collect_insn_data, alter_predicate_for_insn)
>> 	(alter_constraints, subst_dup): Likewise.
>> 	* read-rtl.c (read_rtx_code): Likewise.
>> 	* print-rtl.c (print_rtx): Likewise.
>> 	* genrecog.c (find_operand, find_matching_operand): Likewise.
>> 	(validate_pattern, match_pattern_2): Likewise.
>> 	(parameter::UINT, rtx_test::REGNO_FIELD): New enum values.
>> 	(rtx_test::regno_field): New function.
>> 	(operator ==, safe_to_hoist_p, transition_parameter_type)
>> 	(parameter_type_string, print_parameter_value)
>> 	(print_nonbool_test, print_test): Handle new enum values.
>> 	* cselib.c (rtx_equal_for_cselib_1): Handle REG specially.
>> 	* lra-constraints.c (operands_match_p): Likewise.
> Just to confirm, this doesn't change the size of a REG object, right? 
> If it doesn't change the size, then it's OK.

It doesn't change the size for LP64 hosts.  It makes it 32 bits bigger
for ILP32 hosts.  See https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01598.html
for discussion about that.

If we make the opposite call this time and say that it's better to have
two alternative rtx layouts rather than grow an rtx for ILP32 hosts,
then there are things we could do.  E.g. I doubt an ILP32 host has
enough addressable memory to cope with 1<<24 registers (and associated
instructions), so for ILP32 we could split original_regno into an 8/24
bitfield, using the :8 for the number of registers and the :24 for the
original_regno.  original_regno is so rarely used that an extra shift
or mask shouldn't matter.

Or we could simply leave ILP32 hosts accessing hard_regno_nregs each
time.  The problem then would be that an incorrectly-cached number
of registers would only show up on one type of host.  It would also mean
that REG_NREGS would need to be defined in regs.h for ILP32 at least,
since hard_regno_nregs isn't visible inside rtl.h.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]