public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
@ 2002-08-22 10:21 Ulrich Weigand
  0 siblings, 0 replies; 12+ messages in thread
From: Ulrich Weigand @ 2002-08-22 10:21 UTC (permalink / raw)
  To: dpitts; +Cc: gcc

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-22  8:48 Ulrich Weigand
@ 2002-08-22  9:05 ` Dave Pitts
  0 siblings, 0 replies; 12+ messages in thread
From: Dave Pitts @ 2002-08-22  9:05 UTC (permalink / raw)
  To: Ulrich Weigand; +Cc: gcc

Ulrich Weigand wrote:

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
@ 2002-08-22  8:48 Ulrich Weigand
  2002-08-22  9:05 ` Dave Pitts
  0 siblings, 1 reply; 12+ messages in thread
From: Ulrich Weigand @ 2002-08-22  8:48 UTC (permalink / raw)
  To: dpitts; +Cc: gcc

[-- 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) \

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-22  8:27         ` Kaveh R. Ghazi
@ 2002-08-22  8:31           ` Dave Pitts
  0 siblings, 0 replies; 12+ messages in thread
From: Dave Pitts @ 2002-08-22  8:31 UTC (permalink / raw)
  To: Kaveh R. Ghazi; +Cc: gcc-patches, gcc

Kaveh R. Ghazi wrote:

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-22  8:15       ` Dave Pitts
@ 2002-08-22  8:27         ` Kaveh R. Ghazi
  2002-08-22  8:31           ` Dave Pitts
  0 siblings, 1 reply; 12+ messages in thread
From: Kaveh R. Ghazi @ 2002-08-22  8:27 UTC (permalink / raw)
  To: dpitts; +Cc: gcc-patches, gcc

 > 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-22  8:11     ` Dave Pitts
@ 2002-08-22  8:15       ` Dave Pitts
  2002-08-22  8:27         ` Kaveh R. Ghazi
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Pitts @ 2002-08-22  8:15 UTC (permalink / raw)
  To: dpitts; +Cc: Kaveh R. Ghazi, gcc-patches, gcc

Dave Pitts wrote:

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-22  7:41   ` Kaveh R. Ghazi
@ 2002-08-22  8:11     ` Dave Pitts
  2002-08-22  8:15       ` Dave Pitts
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Pitts @ 2002-08-22  8:11 UTC (permalink / raw)
  To: Kaveh R. Ghazi; +Cc: gcc-patches, gcc

Kaveh R. Ghazi wrote:

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-21 14:12 ` David Edelsohn
  2002-08-21 16:58   ` Dave Pitts
@ 2002-08-22  7:41   ` Kaveh R. Ghazi
  2002-08-22  8:11     ` Dave Pitts
  1 sibling, 1 reply; 12+ messages in thread
From: Kaveh R. Ghazi @ 2002-08-22  7:41 UTC (permalink / raw)
  To: dpitts; +Cc: gcc-patches, gcc

 > 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);

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-21 16:58   ` Dave Pitts
@ 2002-08-21 19:03     ` David Edelsohn
  0 siblings, 0 replies; 12+ messages in thread
From: David Edelsohn @ 2002-08-21 19:03 UTC (permalink / raw)
  To: dpitts; +Cc: gcc

>>>>> 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-21 14:12 ` David Edelsohn
@ 2002-08-21 16:58   ` Dave Pitts
  2002-08-21 19:03     ` David Edelsohn
  2002-08-22  7:41   ` Kaveh R. Ghazi
  1 sibling, 1 reply; 12+ messages in thread
From: Dave Pitts @ 2002-08-21 16:58 UTC (permalink / raw)
  To: David Edelsohn; +Cc: gcc

David Edelsohn wrote:

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Optimizer questions/issues with EBCDIC i370/s390 modes.
  2002-08-21 13:51 Dave Pitts
@ 2002-08-21 14:12 ` David Edelsohn
  2002-08-21 16:58   ` Dave Pitts
  2002-08-22  7:41   ` Kaveh R. Ghazi
  0 siblings, 2 replies; 12+ messages in thread
From: David Edelsohn @ 2002-08-21 14:12 UTC (permalink / raw)
  To: dpitts; +Cc: gcc

>>>>> 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Optimizer questions/issues with EBCDIC i370/s390 modes.
@ 2002-08-21 13:51 Dave Pitts
  2002-08-21 14:12 ` David Edelsohn
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Pitts @ 2002-08-21 13:51 UTC (permalink / raw)
  To: gcc

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




^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2002-08-22 10:21 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-22 10:21 Optimizer questions/issues with EBCDIC i370/s390 modes Ulrich Weigand
  -- strict thread matches above, loose matches on Subject: below --
2002-08-22  8:48 Ulrich Weigand
2002-08-22  9:05 ` Dave Pitts
2002-08-21 13:51 Dave Pitts
2002-08-21 14:12 ` David Edelsohn
2002-08-21 16:58   ` Dave Pitts
2002-08-21 19:03     ` David Edelsohn
2002-08-22  7:41   ` Kaveh R. Ghazi
2002-08-22  8:11     ` Dave Pitts
2002-08-22  8:15       ` Dave Pitts
2002-08-22  8:27         ` Kaveh R. Ghazi
2002-08-22  8:31           ` Dave Pitts

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).