This is the mail archive of the 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]

[PATCH] RFA: Another purge_addressof_1 patch

After further testing found a couple more bugs in purge_addressof_1 I
worked up a new patch here.

Basically what happens is that in a number of testcases (which I'm
working on being able to contribute) we have an addressof replacement
that is cached, however, it doesn't apply to every single case. In
particular, to the notes field that we then decide we can't replace
because we couldn't replace it with the match. I'm pretty sure that this
check has always been wrong.

Also, I've added a check internal to the function to determine whether
or not we have a libcall since that is the only occasion when the
paradoxical subreg should come into play. I also simplified my change
from last time after realizing that checking for both == and < is fairly
easy to simplify. :)

I didn't change any of the comments around the code since they are still
accurate in my reading. I did give them a once over though.

Bootstrapped and tested on x86-linux with no regressions. Tested on
frv-elf and mipsisa64-elf with no regressions.



Eric Christopher <>

2003-11-09  Eric Christopher  <>

	* function.c (purge_addressof_1): Add libcall check.
	Remove test for cached replacements on fallback case.
	Simplify mode comparisons. Add libcall test for
	paradoxical subregs.

Index: function.c
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.465
diff -u -p -w -r1.465 function.c
--- function.c	1 Nov 2003 02:23:44 -0000	1.465
+++ function.c	10 Nov 2003 03:23:59 -0000
@@ -2929,6 +2929,7 @@ purge_addressof_1 (rtx *loc, rtx insn, i
   int i, j;
   const char *fmt;
   bool result = true;
+  bool libcall = false;
   /* Re-start here to avoid recursion in common cases.  */
@@ -2937,6 +2938,10 @@ purge_addressof_1 (rtx *loc, rtx insn, i
   if (x == 0)
     return true;
+  /* Is this a libcall?  */
+  if (!insn)
+    libcall = REG_NOTE_KIND (*loc) == REG_RETVAL;
   code = GET_CODE (x);
   /* If we don't return in any of the cases below, we will recurse
@@ -3070,31 +3075,27 @@ purge_addressof_1 (rtx *loc, rtx insn, i
 		 which can be succinctly described with a simple SUBREG.
 		 Note that removing the REG_EQUAL note is not an option
 		 on the last insn of a libcall, so we must do a replacement.  */
-	      if (! purge_addressof_replacements
-		  && ! purge_bitfield_addressof_replacements)
-		{
 		  /* In compile/990107-1.c:7 compiled at -O1 -m1 for sh-elf,
 		     we got
 		     (mem:DI (addressof:SI (reg/v:DF 160) 159 0x401c8510)
 		      [0 S8 A32]), which can be expressed with a simple
 		     same-size subreg  */
 		  if ((GET_MODE_SIZE (GET_MODE (x))
-		       == GET_MODE_SIZE (GET_MODE (sub)))
+		   <= GET_MODE_SIZE (GET_MODE (sub)))
 		      /* Again, invalid pointer casts (as in
 			 compile/990203-1.c) can require paradoxical
 			 subregs.  */
 			  && (GET_MODE_SIZE (GET_MODE (x))
-			      > GET_MODE_SIZE (GET_MODE (sub))))
-		      || (GET_MODE_SIZE (GET_MODE (x))
-			  < GET_MODE_SIZE (GET_MODE (sub))))
+			  > GET_MODE_SIZE (GET_MODE (sub)))
+		      && libcall))
 		      *loc = gen_rtx_SUBREG (GET_MODE (x), sub, 0);
 		      return true;
 		  /* ??? Are there other cases we should handle?  */
-		}
 	      /* Sometimes we may not be able to find the replacement.  For
 		 example when the original insn was a MEM in a wider mode,
 		 and the note is part of a sign extension of a narrowed

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