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]

[RFC:] Support FORBIDDEN_INC_DEC_CLASS (through FORBIDDEN_INC_DEC_CLASSES)


Scenario for work in progress: a machine supports postincrement
addressing for all general registers except one.  GCC insists on
postincrementing that register despite the port forbidding
postincremented use of the register in GO_IF_LEGITIMATE_ADDRESS.
Sanity check in the port address output functions aborts.

Thankfully, there's infrastructure to handle that case, though
the current implementation handles only some
SECONDARY_RELOAD_CLASS cases.  These cases do not match the
machine in question: the non-postincrementable register can be
moved to and from memory just as any other register, it's just
that it can't be used for postincrement addressing.

Sidenote: why would there be a problem with using postincrement
on the register even if it isn't movable to/from memory (but can
otherwise form an address?  I don't understand that part.

Anyway, I think it's reasonable that GCC could handle the
non-inc-decness.  One way is to remove all the #ifdef
FORBIDDEN_INC_DEC_CLASSES and #ifdef SECONDARY_... and let GCC
iterate over all registers, itself finding out which register
classes are non-inc-dec (in init_reg_autoinc) through calling
memory_address_p (in auto_inc_dec_reg_p).  Another, but less
invasive approach is as below, to let the port describe what
classes are non-inc-dec.

This is a proof-of-concept patch that happens to work for 3.2.1.
I'd like to know if this approach seems suitable for main trunk
some time in the future, or perhaps if something else would be
preferred.

Another question is how to properly make regrename.c consider
FORBIDDEN_INC_DEC_CLASS, since it must not replace e.g. a
postincremented register with a register in a
FORBIDDEN_INC_DEC_CLASS (see tm.texi patch).  I think regrename
should use validate_change and apply_change_group, not just the
(undocumented) HARD_REGNO_RENAME_OK and blindly replacing
registers in the insns as is now.  Then things would Just Work
and it'd be less likely that there'd be future register
replacement problems.

To wit: not tested anywhere that matters.  I'm not asking for
approval to commit, just asking for comments on the approach.

	* doc/tm.texi (Register Classes): Document
	FORBIDDEN_INC_DEC_CLASS.
	* regclass.c (FORBIDDEN_INC_DEC_CLASSES): Also define if
	FORBIDDEN_INC_DEC_CLASS is defined.
	(regclass) [FORBIDDEN_INC_DEC_CLASS]: When setting
	forbidden_inc_dec_class, first test FORBIDDEN_INC_DEC_CLASS.

Index: regclass.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/regclass.c,v
retrieving revision 1.171
diff -c -p -r1.171 regclass.c
*** regclass.c	28 Feb 2003 10:11:47 -0000	1.171
--- regclass.c	26 Mar 2003 17:26:20 -0000
*************** static void init_reg_autoinc	PARAMS ((vo
*** 58,64 ****
     reloads for pseudos auto-incremented since reload can't handle it.  */
  
  #ifdef AUTO_INC_DEC
! #if defined(SECONDARY_INPUT_RELOAD_CLASS) || defined(SECONDARY_OUTPUT_RELOAD_CLASS)
  #define FORBIDDEN_INC_DEC_CLASSES
  #endif
  #endif
--- 58,66 ----
     reloads for pseudos auto-incremented since reload can't handle it.  */
  
  #ifdef AUTO_INC_DEC
! #if defined(SECONDARY_INPUT_RELOAD_CLASS) \
!   || defined(SECONDARY_OUTPUT_RELOAD_CLASS) \
!   || defined(FORBIDDEN_INC_DEC_CLASS)
  #define FORBIDDEN_INC_DEC_CLASSES
  #endif
  #endif
*************** init_reg_autoinc ()
*** 1162,1167 ****
--- 1164,1174 ----
        enum machine_mode m;
        int j;
  
+ #ifdef FORBIDDEN_INC_DEC_CLASS
+       if (FORBIDDEN_INC_DEC_CLASS (i))
+ 	forbidden_inc_dec_class[i] = 1;
+       else
+ #endif
        for (j = 0; j < FIRST_PSEUDO_REGISTER; j++)
  	if (TEST_HARD_REG_BIT (reg_class_contents[i], j))
  	  {
Index: doc/tm.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.208
diff -c -p -r1.208 tm.texi
*** doc/tm.texi	11 Mar 2003 20:40:52 -0000	1.208
--- doc/tm.texi	26 Mar 2003 17:26:20 -0000
*************** reallocation, you should not change the 
*** 2594,2599 ****
--- 2594,2616 ----
  the only effect of such a definition would be to slow down register
  allocation.
  
+ @findex FORBIDDEN_INC_DEC_CLASS (@var{class})
+ @anchor{forbidden_inc_dec_class}
+ A machine may support pre- or post- increment or decrement
+ addressing modes (@pxref{addressing modes}) for some registers,
+ but not for others.  For such a machine, define at least one
+ register class that contains @emph{only} registers not
+ supporting those addressing modes.  Define this macro as a C
+ expression whose value is nonzero if @var{class} is one of those
+ register classes.  If you define this macro, you also need to
+ define @code{HARD_REGNO_RENAME_OK}
+ @c FIXME: Unfortunately that macro is undocumented.  When
+ @c documented, add a @pxref to it.
+ to refuse renames from other registers to any register in a
+ class for which @code{FORBIDDEN_INC_DEC_CLASS} returns nonzero.
+ @c FIXME: That's a wart: regrename.c should handle
+ @c FORBIDDEN_INC_DEC_CLASS.
+ 
  @findex CLASS_MAX_NREGS
  @item CLASS_MAX_NREGS (@var{class}, @var{mode})
  A C expression for the maximum number of consecutive registers
*************** This is about addressing modes.
*** 4852,4857 ****
--- 4869,4875 ----
  @itemx HAVE_POST_DECREMENT
  A C expression that is nonzero if the machine supports pre-increment,
  pre-decrement, post-increment, or post-decrement addressing respectively.
+ @xref{forbidden_inc_dec_class}.
  
  @findex HAVE_POST_MODIFY_DISP
  @findex HAVE_PRE_MODIFY_DISP

brgds, H-P


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