Optimizer questions/issues with EBCDIC i370/s390 modes.

Optimizer questions/issues with EBCDIC i370/s390 modes.

[Dave Pitts]

Hello:

I've a few questions concerning the operation of the optimizer when cross
compiling on an ASCII based system for an EBCDIC based system. These
things work correctly when compiling natively on an EBCDIC system. I'm
using the 3.2 release with my i370 changes.

1. Short string literals are converted to integers (CONST_INT) are not
converted to EBCDIC.

Code like:

   strcpy (foo, ":");

generates:

   L    2, =A(FOO)
   MVC    0(2,2),=H'11776'

The value 11776 is the ASCII values for ':' and null. I've looked 
through the
source and I can't  locate where this is being done.

2. Outputing of constant strings with printf are converted to puts when 
running
native.

Code like:

   printf ("some printed stuff\n");

generates natively:

LC01    EQU    *
   DC C'some printed stuff'
   DC    X'0'
...
   MVC 148(4,13),=A(LC01)
   LA    1,148(13)
   L    15,=V(PUTS)
   BALR    14,15

generates on cross compile:

LC01    EQU    *
   DC C'some printed stuff'
   DC    X'15'            EBCDIC NEWLINE
   DC    X'0'
...
   MVC 148(4,13),=A(LC01)
   LA    1,148(13)
   L    15,=V(PRINTF)
   BALR    14,15

It appears that the optimizer is looking for a native \n and not 
TARGET_NEWLINE.


3. This fails in both native and cross compile modes. The macros in 
longlong.h for
the i370 appear to fail when compiling _udiv_w_sdiv:

./xgcc -B./ -B/usr/local/i370-ibm-openedition/bin/ -isystem 
/usr/local/i370-ibm-openedition/include -isystem 
/usr/local/i370-ibm-openedition/sys-include -S -O2  -DIN_GCC 
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -isystem ./include     -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-3.2/gcc 
-I../../gcc-3.2/gcc/. -I../../gcc-3.2/gcc/config 
-I../../gcc-3.2/gcc/../include  -DL_udiv_w_sdiv -c 
../../gcc-3.2/gcc/libgcc2.c -fexceptions -fnon-call-exceptions -o 
libgcc/./_udiv_w_sdiv.o
../../gcc-3.2/gcc/libgcc2.c: In function `__udiv_w_sdiv':
../../gcc-3.2/gcc/libgcc2.c:403: `asm' operand requires impossible reload
../../gcc-3.2/gcc/libgcc2.c:427: `asm' operand requires impossible reload
make[1]: *** [libgcc/./_udiv_w_sdiv.o] Error 1

What causes and "impossible reload"?

The longlong.h code fragment is:

#if (defined (__i370__) || defined (__mvs__)) && W_TYPE_SIZE == 32
#define umul_ppmm(xh, xl, m0, m1) \
 do {                                                                  \
   union {UDItype __ll;                                                \
          struct {USItype __h, __l;} __i;                              \
         } __xx;                                                       \
   USItype __m0 = (m0), __m1 = (m1);                                   \
   __asm__ ("mr %0,%3"                                                 \
            : "=r" (__xx.__i.__h),                                     \
              "=r" (__xx.__i.__l)                                      \
            : "%1" (__m0),                                             \
              "r" (__m1));                                             \
   (xh) = __xx.__i.__h; (xl) = __xx.__i.__l;                           \
   (xh) += ((((SItype) __m0 >> 31) & __m1)                             \
            + (((SItype) __m1 >> 31) & __m0));                         \
 } while (0)
#define smul_ppmm(xh, xl, m0, m1) \
 do {                                                                  \
   union {DItype __ll;                                                 \
          struct {USItype __h, __l;} __i;                              \
         } __xx;                                                       \
   __asm__ ("mr %0,%3"                                                 \
            : "=r" (__xx.__i.__h),                                     \
              "=r" (__xx.__i.__l)                                      \
            : "%1" (m0),                                               \
              "r" (m1));                                               \
   (xh) = __xx.__i.__h; (xl) = __xx.__i.__l;                           \
 } while (0)
#define sdiv_qrnnd(q, r, n1, n0, d) \
 do {                                                                  \
   union {DItype __ll;                                                 \
          struct {USItype __h, __l;} __i;                              \
         } __xx;                                                       \
   __xx.__i.__h = n1; __xx.__i.__l = n0;                               \
   __asm__ ("dr %0,%2"                                                 \
            : "=r" (__xx.__ll)                                         \
            : "0" (__xx.__ll), "r" (d));                               \
   (q) = __xx.__i.__l; (r) = __xx.__i.__h;                             \
 } while (0)
#endif

What is this code doing? I didn't write it and I'm unfamiliar with the
syntax.

Thanks in advance.

--
Dave Pitts                   PULLMAN: Travel and sleep in safety and comfort.
dpitts@cozx.com              My other RV IS a Pullman (Colorado Pine). 
http://www.cozx.com/~dpitts

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[David Edelsohn]

>>>>> Dave Pitts writes:

Dave> I've a few questions concerning the operation of the optimizer when cross
Dave> compiling on an ASCII based system for an EBCDIC based system. These
Dave> things work correctly when compiling natively on an EBCDIC system. I'm
Dave> using the 3.2 release with my i370 changes.

	The right place to begin looking for strcpy and printf
optimizations probably  is builtins.c and c-common.c.

	The asms are trying to inline 32x32->64 multiply and equivalent
divide.  I think that impossible reload means that GCC can't figure out
how to generate valid instructions to move the arguments into the
registers required by the asm constraints.  Maybe the s390 port can
provide some guidance?

David

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Dave Pitts]

David Edelsohn wrote:

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[David Edelsohn]

>>>>> Dave Pitts writes:

Dave> The s390 mode doesn't have any longlong.h entries.  I'll have to think 
Dave> about this one.
Dave> Any idea who wrote these macros? They may have some insight.

	Maybe Kenner or Marist or MKS or whoever did the original i370
port.  I would not look to the original author for help.

	Inline asm is very similar to the MD file patterns.  I didn't mean
look at longlong.h for S/390, I meant look at s390.md and i370.md to see
how they handled the "MR" multiply instruction constraints.

	Maybe it just needs "d" DATA_REGS constraints instead of "r"?

David

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Kaveh R. Ghazi]

 > 2. Outputing of constant strings with printf are converted to puts
 > when running native.
 > 
 > It appears that the optimizer is looking for a native \n and not
 > TARGET_NEWLINE.

Does this (as of yet untested) patch help?

2002-08-22  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* c-common.c (c_expand_builtin_printf): Use TARGET_NEWLINE.

Index: c-common.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.366
diff -u -p -r1.366 c-common.c
--- c-common.c	16 Aug 2002 23:31:03 -0000	1.366
+++ c-common.c	22 Aug 2002 14:27:06 -0000
@@ -4513,10 +4513,10 @@ c_expand_builtin_printf (arglist, target
          includes the terminating NULL in its count.  */
       else if (TREE_STRING_LENGTH (stripped_string) > 2
 	       && TREE_STRING_POINTER (stripped_string)
-	       [TREE_STRING_LENGTH (stripped_string) - 2] == '\n')
+	       [TREE_STRING_LENGTH (stripped_string) - 2] == TARGET_NEWLINE)
         {
 	  /* Create a NULL-terminated string that's one char shorter
-	     than the original, stripping off the trailing '\n'.  */
+	     than the original, stripping off the trailing TARGET_NEWLINE.  */
 	  const int newlen = TREE_STRING_LENGTH (stripped_string) - 1;
 	  char *newstr = (char *) alloca (newlen);
 	  memcpy (newstr, TREE_STRING_POINTER (stripped_string), newlen - 1);

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Dave Pitts]

Kaveh R. Ghazi wrote:

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Dave Pitts]

Dave Pitts wrote:

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Kaveh R. Ghazi]

 > From: Dave Pitts <dpitts@cozx.com>
 > 
 > Oops, had the files backwards. Here's the correct patch:
 > 
 > --- c-common.c.orig     Wed Aug 21 15:17:02 2002
 > +++ c-common.c  Thu Aug 22 09:03:34 2002
 > @@ -3924,6 +3924,14 @@ c_expand_builtin_printf (arglist, target
 >           /* Given printf("c"), (where c is any one character,)
 >               convert "c"[0] to an int and pass that to the replacement
 >               function.  */
 > +#ifdef MAP_OUTCHAR
 > +         {
 > +           unsigned x = MAP_OUTCHAR(TREE_STRING_POINTER 
 > (stripped_string)[0]);
 > +           arglist = build_int_2 (x, 0);
 > +         }
 > +#else
 > +         arglist = build_int_2 (TREE_STRING_POINTER 
 > (stripped_string)[0], 0);
 > +#endif
 >           arglist = build_int_2 (TREE_STRING_POINTER 
 > (stripped_string)[0], 0);

Shouldn't you remove this last line here?  Did you test it?
(I think it overwrites your MAP_OUTCHAR case.)

--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Dave Pitts]

Kaveh R. Ghazi wrote:

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Ulrich Weigand]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Dave Pitts wrote:

>3. This fails in both native and cross compile modes. The macros in
>longlong.h for the i370 appear to fail when compiling _udiv_w_sdiv:

Yes, they are broken.  They try to express a matching constraint
between a single-register operand and one subreg of a multi-register
operand, which unfortunately reload doesn't support (would be nice
if it did ...).

I've been experimenting with this patch
(See attached file: longlong.diff)
which fixes the broken constraints (at the cost of more inefficient code)
and activates the longlong.h macros also for s390.  (This version of
longlong.h corresponds to the one from GMP, b.t.w.)

If this works for you, we could look into integrating this patch.



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com
Attachment:
longlong.diff
Description: Binary data


[-- Attachment #2: longlong.diff --]
[-- Type: text/x-diff, Size: 2362 bytes --]

Index: gcc/longlong.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/longlong.h,v
retrieving revision 1.27
diff -c -p -r1.27 longlong.h
*** gcc/longlong.h	9 Feb 2002 03:08:05 -0000	1.27
--- gcc/longlong.h	11 Apr 2002 12:29:02 -0000
*************** UDItype __umulsidi3 (USItype, USItype);
*** 400,417 ****
    } while (0)
  #endif
  
! #if (defined (__i370__) || defined (__mvs__)) && W_TYPE_SIZE == 32
  #define umul_ppmm(xh, xl, m0, m1) \
    do {									\
      union {UDItype __ll;						\
  	   struct {USItype __h, __l;} __i;				\
  	  } __xx;							\
      USItype __m0 = (m0), __m1 = (m1);					\
!     __asm__ ("mr %0,%3"							\
! 	     : "=r" (__xx.__i.__h),					\
! 	       "=r" (__xx.__i.__l)					\
! 	     : "%1" (__m0),						\
! 	       "r" (__m1));						\
      (xh) = __xx.__i.__h; (xl) = __xx.__i.__l;				\
      (xh) += ((((SItype) __m0 >> 31) & __m1)				\
  	     + (((SItype) __m1 >> 31) & __m0));				\
--- 400,415 ----
    } while (0)
  #endif
  
! #if (defined (__i370__) || defined (__s390__) || defined (__mvs__)) && W_TYPE_SIZE == 32
  #define umul_ppmm(xh, xl, m0, m1) \
    do {									\
      union {UDItype __ll;						\
  	   struct {USItype __h, __l;} __i;				\
  	  } __xx;							\
      USItype __m0 = (m0), __m1 = (m1);					\
!     __asm__ ("lr %N0,%1\n\tmr %0,%2"					\
! 	     : "=&r" (__xx.__ll)					\
! 	     : "r" (__m0), "r" (__m1));					\
      (xh) = __xx.__i.__h; (xl) = __xx.__i.__l;				\
      (xh) += ((((SItype) __m0 >> 31) & __m1)				\
  	     + (((SItype) __m1 >> 31) & __m0));				\
*************** UDItype __umulsidi3 (USItype, USItype);
*** 421,431 ****
      union {DItype __ll;							\
  	   struct {USItype __h, __l;} __i;				\
  	  } __xx;							\
!     __asm__ ("mr %0,%3"							\
! 	     : "=r" (__xx.__i.__h),					\
! 	       "=r" (__xx.__i.__l)					\
! 	     : "%1" (m0),						\
! 	       "r" (m1));						\
      (xh) = __xx.__i.__h; (xl) = __xx.__i.__l;				\
    } while (0)
  #define sdiv_qrnnd(q, r, n1, n0, d) \
--- 419,427 ----
      union {DItype __ll;							\
  	   struct {USItype __h, __l;} __i;				\
  	  } __xx;							\
!     __asm__ ("lr %N0,%1\n\tmr %0,%2"					\
! 	     : "=&r" (__xx.__ll)					\
! 	     : "r" (m0), "r" (m1));					\
      (xh) = __xx.__i.__h; (xl) = __xx.__i.__l;				\
    } while (0)
  #define sdiv_qrnnd(q, r, n1, n0, d) \

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Dave Pitts]

Ulrich Weigand wrote:

Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

[Ulrich Weigand]

Dave Pitts wrote:

>The error seems to point at the sdiv_qrnnd macro:

However, that macro looks perfectly OK to me, and in fact it works
on s390.

>../../gcc-3.2/gcc/libgcc2.c: In function `__udiv_w_sdiv':
>../../gcc-3.2/gcc/libgcc2.c:403: `asm' operand requires impossible reload
>../../gcc-3.2/gcc/libgcc2.c:427: `asm' operand requires impossible reload

I've checked this with a cross-compiler to i370-ibm-openedition,
and get the same error.  This appears to be caused by a problem
in the i370 backend.

What happens is that the compiler generates a DImode reload insn of the
form
  (set (reg:DI 0) (reg:DI 49))
for a pseudo 49, which gets assigned a stack slot.

This insn is then rejected by the backend as invalid, which is a bug
in the backend, as any move insn must be valid.

The problem is that the reg:DI 49 operand matches a r_or_s_operand
predicate (because it's a REG), therefore the insn matches this pattern:

  [(set (match_operand:DI 0 "r_or_s_operand" "=dS,m")
        (match_operand:DI 1 "r_or_s_operand" "diS*fF,d*fF"))]

However, as the pseudo was allocated a stack slot, it matches neither
the diS*fF nor the d*fF constraint in strict mode and is thus rejected.
This needs to be fixed; for a move pattern, the constraints need to accept
anything allowed by the predicate (and the predicate really should be
general_operand anyway).  (For other patterns, this requirement is not
quite that strict as reload can fix things up, but for moves, reload
relies on the backend to accept basically anything.)


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com