gcc-patches@gcc.gnu.org
[Top] [All Lists]

Re: PR middle-end/25121: [4.1/4.2 Regression] libgcj misscompilation? [W

Subject: Re: PR middle-end/25121: [4.1/4.2 Regression] libgcj misscompilation? [Was Re: RFC: peephole vs RTX_FRAME_RELATED_P]
From: Andrew Haley
Date: Tue, 20 Dec 2005 19:34:08 +0000
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@xxxxxxxxxx>

        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

<Prev in Thread] Current Thread [Next in Thread>