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]

init_reg_autoinc bug and how to describe regs that can't autoincdec


This patch fixes the bug that the parameters in the two calls to
secondary_reload_class were the same, where the in/out parameter was
supposed to be different.  That was just an oversight in Joern's
infrastructure change at r107468 (diff to r107467 to see).

But there's another problem here, due to a construct which seems to
have been introduced with a commit by Richard Kenner in 1994
(translated as r6461 in svn).  Classes are not marked as forbidden
where (some) member registers can't be used for autoincdec, *unless*
at least one of those register *also* needs a secondary reload for a
move to/from the preferred class to hold a POST_INC.  This way, you
can't get correct forbidden_inc_dec_class settings for a register
[class] that can't be incdec'd but doesn't need secondary reloads,
which is the problem I'm having.  It's for a new variant of CRIS that
I hope to commit as soon as I get rid of test-results regressions;
this one register is preferred for any address that doesn't
autoincdec.

The breakage is seen as the register-that-can't-be-autoinced being
allocated for post_inc addresses in global.  "It works" with a hack
using TARGET_SECONDARY_RELOAD to fake secondary reloads to appease
just this code, causing forbidden_inc_dec_class[i] to be set to 1 for
classes where that register is a member.  FWIW, this code only checks
whether an autoincdec address is valid as per
GO_IF_LEGITIMATE_ADDRESS.  The target macros MODE_CODE_BASE_REG_CLASS
and REGNO_MODE_CODE_OK_FOR_BASE_P aren't consulted here, except for
forming base_class, which doesn't affect much.

The intended conditional seen below would more intuitively be to
forbid classes where some member can't autoincdec *or* the class needs
secondary reloads to get to base_class (the preferred class for
autoincdec).  Presumably the part about secondary reloads to
base_class is a heuristic to say it's not be worth it if you need
secondary reloads for any moves within the same class, otherwise I
don't understand what it has to do with validity of autoincdec in
class i.  Nevertheless, I tried changing the "&& !" to "|| !" but
noticed size regressions in libgcc.a for sh-elf (which needs reloads
to a large extent), so that's out.  Similarly with the
secondary_reload_class calls removed.

So, the main question is, how should this code change to also work for
a register class that can't be used for autoincdeced but doesn't need
secondary reloads at all?

Anyway, the simpler typo patch below was committed as obvious after
testing on on crosses to sh, cris and arm -elf (incdec targets) and
seeing no change in their libgcc.a's.  The context shows the construct
described above; this is the only place where forbidden_inc_dec_class
is changed to 1.

	* regclass.c (init_reg_autoinc): Fix typo preventing test of
	secondary output reload when setting forbidden_inc_dec_class.

Index: regclass.c
===================================================================
--- regclass.c	(revision 130332)
+++ regclass.c	(working copy)
@@ -1282,7 +1282,7 @@ init_reg_autoinc (void)
 		     requires secondary reloads, disallow its class from
 		     being used in such addresses.  */
 
-		  if ((secondary_reload_class (1, base_class, m, r)
+		  if ((secondary_reload_class (0, base_class, m, r)
 		       || secondary_reload_class (1, base_class, m, r))
 		      && ! auto_inc_dec_reg_p (r, m))
 		    forbidden_inc_dec_class[i] = 1;

brgds, H-P


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