Re: Call for testers, ppc64-linux

Re: Call for testers, ppc64-linux

[Janis Johnson]

On Fri, 2008-09-05 at 02:03 +0200, Hans-Peter Nilsson wrote:
> Could someone on a ppc64-linux system please regtest the patch
> in PR37363, <http://gcc.gnu.org/bugzilla/attachment.cgi?id=16217>,
> in-message below, on a ppc64-linux system with a trunk baseline
> not older than svn revision 139763?  If it helps, that patch is
> already on the 4.3 branch, I just want to make sure it's not
> regressing PR36090 on trunk.  Many thanks in advance.

I'll do it.

Janis

Call for testers, ppc64-linux

[Hans-Peter Nilsson]

Could someone on a ppc64-linux system please regtest the patch
in PR37363, <http://gcc.gnu.org/bugzilla/attachment.cgi?id=16217>,
in-message below, on a ppc64-linux system with a trunk baseline
not older than svn revision 139763?  If it helps, that patch is
already on the 4.3 branch, I just want to make sure it's not
regressing PR36090 on trunk.  Many thanks in advance.

Index: simplify-rtx.c
===================================================================
--- simplify-rtx.c	(revision 139963)
+++ simplify-rtx.c	(working copy)
@@ -3678,24 +3678,6 @@
      one CONST_INT, and the sort will have ensured that it is last
      in the array and that any other constant will be next-to-last.  */
 
-  if (GET_CODE (ops[n_ops - 1].op) == CONST_INT)
-    i = n_ops - 2;
-  else
-    i = n_ops - 1;
-
-  if (i >= 1
-      && ops[i].neg
-      && !ops[i - 1].neg
-      && CONSTANT_P (ops[i].op)
-      && GET_CODE (ops[i].op) == GET_CODE (ops[i - 1].op))
-    {
-      ops[i - 1].op = gen_rtx_MINUS (mode, ops[i - 1].op, ops[i].op);
-      ops[i - 1].op = gen_rtx_CONST (mode, ops[i - 1].op);
-      if (i < n_ops - 1)
-	ops[i] = ops[i + 1];
-      n_ops--;
-    }
-
   if (n_ops > 1
       && GET_CODE (ops[n_ops - 1].op) == CONST_INT
       && CONSTANT_P (ops[n_ops - 2].op))
Index: config/rs6000/rs6000.c
===================================================================
--- config/rs6000/rs6000.c	(revision 139963)
+++ config/rs6000/rs6000.c	(working copy)
@@ -12493,6 +12493,10 @@
 	      XSTR (symref, 0) = newname;
 	    }
 	  output_addr_const (file, XEXP (x, 1));
+	  if (GET_CODE (XEXP (minus, 1)) == CONST
+	      && (GET_CODE (XEXP (XEXP (minus, 1), 0)) == PLUS))
+	    fprintf (file, "+"HOST_WIDE_INT_PRINT_DEC,
+		     -INTVAL (XEXP (XEXP (XEXP (minus, 1), 0), 1)));
 	  if (TARGET_ELF)
 	    XSTR (symref, 0) = name;
 	  XEXP (contains_minus, 0) = minus;

brgds, H-P

PR37363: PR36090 and PR36182 all over again (was: Re: Call for testers, ppc64-linux)

[Hans-Peter Nilsson]

> From: Janis Johnson <janis187@us.ibm.com>
> Date: Thu, 04 Sep 2008 17:20:47 -0700

> On Fri, 2008-09-05 at 02:03 +0200, Hans-Peter Nilsson wrote:
> > Could someone on a ppc64-linux system please regtest the patch
> > in PR37363, <http://gcc.gnu.org/bugzilla/attachment.cgi?id=16217>,
> > in-message below, on a ppc64-linux system with a trunk baseline
> > not older than svn revision 139763?  If it helps, that patch is
> > already on the 4.3 branch, I just want to make sure it's not
> > regressing PR36090 on trunk.  Many thanks in advance.
> 
> I'll do it.

I got negative feedback on that patch (no, not regression
results :) on IRC from David Edelsohn and understandably you
held off your testing because of this, as for one the patch
affects the rs6000 backend.

I'll look a bit closer because I'm not sure I see the cause of
the objection.  There was talk about non-canonical RTL generated
but I'd like to see it; the earlier discussion just indicates
insufficient predicates in the rs6000 backend but maybe I
misunderstood.

In the meantime, can I please ask Paolo Bonzini for advice on
how to proceed?  (Involved in PR36090 as well the original code
and also PR36182 from which PR37363 was cloned.)

For CRIS (as well as other targets IIUC) the cause of PR37363 is
that there's code that wraps a MINUS of two symbol_ref's in a
CONST without checking that the two symbol_ref's make up a valid
address.  After that, the CONST effectively acts as a barrier
for target hooks ("no need to look, we know that thing there is
a valid constant expression").

brgds, H-P