PR middle-end/25121: [4.1/4.2 Regression] libgcj misscompilation? [Was Re: RFC: peephole vs RTX_FRAME_RELATED_P]

[Andrew Haley]

Richard Henderson writes:
 > On Tue, Dec 20, 2005 at 05:29:11PM +0000, Andrew Haley wrote:
 > > Oh, joy.  Now I have to figure out what peep2_current_count is doing...
 > 
 > Counting the number of sequential valid instructions in the buffer.
 > Reset it to zero when you find a frame insn.

Yes, I see.

Andrew.


2005-12-20  Andrew Haley  <aph@redhat.com>

	PR middle-end/25121
	* recog.c (peephole2_optimize): Don't peephole any
	RTX_FRAME_RELATED_P insns.

Index: recog.c
===================================================================
--- recog.c	(revision 108424)
+++ recog.c	(working copy)
@@ -3118,8 +3118,18 @@
 	      propagate_one_insn (pbi, insn);
 	      COPY_REG_SET (peep2_insn_data[peep2_current].live_before, live);
 
-	      /* Match the peephole.  */
-	      try = peephole2_insns (PATTERN (insn), insn, &match_len);
+	      if (RTX_FRAME_RELATED_P (insn))
+		{
+		  /* If an insn has RTX_FRAME_RELATED_P set, peephole
+		     substitution would lose the
+		     REG_FRAME_RELATED_EXPR that is attached.  */
+		  peep2_current_count = 0;
+		  try = NULL;
+		}
+	      else
+		/* Match the peephole.  */
+		try = peephole2_insns (PATTERN (insn), insn, &match_len);
+
 	      if (try != NULL)
 		{
 		  /* If we are splitting a CALL_INSN, look for the CALL_INSN