Gary Thomas: Code optimization bug in GCC-2.8 & EGCS

[David Edelsohn <dje at watson dot ibm dot com>]

	duplicate_loop_exit_text() in jump.c searches the exit test code
to potentially duplicate it but limits the number of instructions to 20,
from the comments:

	If the code is sufficiently simple, make a copy of it before INSN
	Also, don't do this if the exit code is more than 20 insns.

I do not know how this heuristic was determined, but it seems to be
incorrect for some PowerPC cases.  Gary's appended patch increases the
value to 50 which fixes the particular example.  From his explanation, it
sounds like CSE reorganizes the code incorrectly and this patch simply
masks that problem.  I am not sure why *any* value for the search is
appropriate -- especially on all architectures.

David

------- Forwarded Message

Date: Fri, 30 Jan 1998 17:23:16 +0100 (MET)
Organization: The Open Group / Research Institute
Sender: gary@gr.opengroup.org
From: Gary Thomas <g.thomas@opengroup.org>
To: David Edelsohn <dje@watson.ibm.com>,
        Michael Meissner <meissner@cygnus.com>
Subject: Code optimization bug in GCC-2.8 & EGCS

This message is in MIME format
--_=XFMail.1.2.p0.Linux:980130172316:4652=_
Content-Type: text/plain; charset=us-ascii

The PowerPC/RS6000 code generator will generate bad code when compiled
with these options "-O2 -fsigned-char" (or any combination that get's
signed characters) on this fragment:

#include <stdio.h>

#ifndef __char
#define __char signed char
#endif

#define cr_or_whitespace(c) (((c) == '\t') || ((c) == ' ') || ((c) == '\n'))

int
what_section (text)
     __char *text;
{
  /*register*/ int i, j;
  __char *t;

  for (j = 0; text[j] && !cr_or_whitespace (text[j]); j++);
  return (j);
}

main()
{
  printf("what_section(chapter) = %d\n", what_section("@chapter\n"));
}

If you look at the generated code, you'll see that it is actually accessing
the [j+1] character in each case because of the incorrect code.

The problem is that the "jump" optimizer pass gives up the first time it's
called and the cse (follow jumps) reorganizes the code incorrectly.  The
fix is quite simple, just let "jump" look at longer sequences (patch attached).

------------------------------------------------------------------------
Gary Thomas                              |
The Open Group / Research Institute      | "Fine wine is a necessity of
2 Avenue de Vignate                      |        life for me"
38610 Gieres - FRANCE                    |
+33 4 76 63 48 74                        |      Thomas Jefferson
email: g.thomas@opengroup.org            |
<http://www.opengroup.org/~gdt>          |
   ... opinions expressed here are mine  |
       and no one else would claim them! |
------------------------------------------------------------------------

--_=XFMail.1.2.p0.Linux:980130172316:4652=_
Content-Disposition: attachment; filename="gcc-2.8.0-ppc_jump.patch"
Content-Transfer-Encoding: 7bit
Content-Description: gcc-2.8.0-ppc_jump.patch
Content-Type: text/plain;
 charset=us-ascii; name=gcc-2.8.0-ppc_jump.patch; SizeOnDisk=336

--- gcc-2.8.0/jump.c	Wed Jan  7 23:30:23 1998
+++ gcc-2.8.0.NEW/jump.c	Fri Jan 30 15:55:13 1998
@@ -2334,7 +2334,7 @@
 	  break;
 	case JUMP_INSN:
 	case INSN:
-	  if (++num_insns > 20
+	  if (++num_insns > 50
 	      || find_reg_note (insn, REG_RETVAL, NULL_RTX)
 	      || find_reg_note (insn, REG_LIBCALL, NULL_RTX))
 	    return 0;

--_=XFMail.1.2.p0.Linux:980130172316:4652=_--
End of MIME message

------- End of Forwarded Message