RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Hello,

Ada builds are currently failing on s390x due to missing __divti3.

Now, I guess we could add 128-bit division routines to libgcc.
However, the question is whether this should really be needed.

What appears to happen is that the Ada source in question defines
a variable-sized object with non-standard alignment requirements,
and Ada reflects this by building a DECL_SIZE_UNIT tree containing
various mult_expr and div_expr nodes.  As alignment is counted in
bits, those have type bit_size_type, which on 64-bit platforms
corresponds to TImode. When expanding that tree, the backend emits
calls to __divti3.

However, I'm wondering:

- does bit_size_type really need to be TImode
- if so, shouldn't these special cases be implemented more efficiently
  somewhere (we divide by an integer constant 8 here)
- in general, are we really supposed to need TImode division

How does this work on other 64-bit platforms?


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

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Richard Henderson]

On Thu, Mar 20, 2003 at 09:58:58PM +0100, Ulrich Weigand wrote:
> Ada builds are currently failing on s390x due to missing __divti3.

That shouldn't be happening.  They get built for e.g. alpha and ia64...


r~

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Geert Bosch]

On Thursday, Mar 20, 2003, at 15:58 America/New_York, Ulrich Weigand 
wrote:

> However, I'm wondering:
>
> - does bit_size_type really need to be TImode
Richard Kenner would be best qualified to answer this, but he is out
of town until tuesday.
> - if so, shouldn't these special cases be implemented more efficiently
>   somewhere (we divide by an integer constant 8 here)

This would be nice, but I'm not sure this is most pressing. It seems
unlikely to me that the constructs generating these long divisions
would occur in performance-sensitive code.
In general, for 64-bit arithmetic operations on 32-bit targets, there
are many cases where one of the operands is constant and simpler
code code be generated inline instead.

> - in general, are we really supposed to need TImode division
> How does this work on other 64-bit platforms?

Other 64-bit platforms define TImode division.

   -Geert

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Janis Johnson]

On Thu, Mar 20, 2003 at 09:58:58PM +0100, Ulrich Weigand wrote:
> Hello,
> 
> Ada builds are currently failing on s390x due to missing __divti3.
> 
> How does this work on other 64-bit platforms?

You can change the value of MIN_UNITS_PER_WORD when compiling libgcc2.c.
For example, in config/rs6000/rs6000.h:

/* Width of a word, in units (bytes).  */
#define UNITS_PER_WORD (! TARGET_POWERPC64 ? 4 : 8)
#ifdef IN_LIBGCC2
#define MIN_UNITS_PER_WORD UNITS_PER_WORD
#else
#define MIN_UNITS_PER_WORD 4
#endif

This can cause some needed DImode functions to disappear; if that
happens, you'll need to find a way to add them again.  That happened
for soft-float support for powerpc64-unknown-linux-gnu.

Janis

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Richard Henderson wrote:

>On Thu, Mar 20, 2003 at 09:58:58PM +0100, Ulrich Weigand wrote:
>> Ada builds are currently failing on s390x due to missing __divti3.
>
>That shouldn't be happening.  They get built for e.g. alpha and ia64...

Well, I guess I can find out why divti3 doesn't get built.  However,
the IMO really interesting question is why TImode division should be
needed -- calling __divti3 just to make sure that a variable is 8-byte
aligned on the stack strikes me as seriously suboptimal ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Richard Henderson]

On Thu, Mar 20, 2003 at 11:11:50PM +0100, Ulrich Weigand wrote:
> Well, I guess I can find out why divti3 doesn't get built.  However,
> the IMO really interesting question is why TImode division should be
> needed -- calling __divti3 just to make sure that a variable is 8-byte
> aligned on the stack strikes me as seriously suboptimal ...

Huh?  We've computed its size, in bits.  We need 67-bit
arithmetic for this, technically.  Not that I actually
believe that someone is going to create a 2EB dynamically
sized object...



r~

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Neil Booth]

Richard Henderson wrote:-

> On Thu, Mar 20, 2003 at 11:11:50PM +0100, Ulrich Weigand wrote:
> > Well, I guess I can find out why divti3 doesn't get built.  However,
> > the IMO really interesting question is why TImode division should be
> > needed -- calling __divti3 just to make sure that a variable is 8-byte
> > aligned on the stack strikes me as seriously suboptimal ...
> 
> Huh?  We've computed its size, in bits.  We need 67-bit
> arithmetic for this, technically.  Not that I actually
> believe that someone is going to create a 2EB dynamically
> sized object...

I dunno, give GCC another 5 years...

Neil.

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Richard Henderson wrote:
> On Thu, Mar 20, 2003 at 11:11:50PM +0100, Ulrich Weigand wrote:
> > Well, I guess I can find out why divti3 doesn't get built.  However,
> > the IMO really interesting question is why TImode division should be
> > needed -- calling __divti3 just to make sure that a variable is 8-byte
> > aligned on the stack strikes me as seriously suboptimal ...
> 
> Huh?  We've computed its size, in bits.  We need 67-bit
> arithmetic for this, technically.  Not that I actually
> believe that someone is going to create a 2EB dynamically
> sized object...

Well, but we don't need the size in bits when computing stack
alignment.  It should be possible to compute the size in bytes
without requiring 67-bit arithmetic ...  I just find it weird
to require full-blown 128-bit arithmetic which is not actually
accessible to the user, and needed only at this place (where
it should be actually avoidable).

In any case, if that's the way it is, then so be it. ;-)
I'll just fix the MIN_UNITS_PER_WORD define to get 128-bit
libgcc2 routines built.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Richard Henderson]

On Fri, Mar 21, 2003 at 02:15:36AM +0100, Ulrich Weigand wrote:
> Well, but we don't need the size in bits when computing stack
> alignment.

True.  Perhaps you can find out why we're doing this?

> I'll just fix the MIN_UNITS_PER_WORD define to get 128-bit
> libgcc2 routines built.

This is good as well.


r~

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Richard Henderson wrote:

> On Fri, Mar 21, 2003 at 02:15:36AM +0100, Ulrich Weigand wrote:
> > Well, but we don't need the size in bits when computing stack
> > alignment.
> 
> True.  Perhaps you can find out why we're doing this?

I'll have a look.

> > I'll just fix the MIN_UNITS_PER_WORD define to get 128-bit
> > libgcc2 routines built.
> 
> This is good as well.

I've applied the following patch to fix this to both 3.3 branch
and CVS head; bootstrap (including Ada) and regtest pass on both
branches on s390-ibm-linux and s390x-ibm-linux now.


ChangeLog:

	* config/s390/s390.h: Do not include fixdfdi.h on s390x.
	(TARGET_64BIT): Define as compile-time constant when IN_LIBGCC2.
	(MIN_UNITS_PER_WORD): Do not define when IN_LIBGCC2.


Index: gcc/config/s390/s390.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.h,v
retrieving revision 1.53.2.4
diff -c -p -r1.53.2.4 s390.h
*** gcc/config/s390/s390.h	31 Jan 2003 23:51:23 -0000	1.53.2.4
--- gcc/config/s390/s390.h	21 Mar 2003 01:53:14 -0000
*************** Boston, MA 02111-1307, USA.  */
*** 24,30 ****
  
  /* Override the __fixdfdi etc. routines when building libgcc2.
     ??? This should be done in a cleaner way ...  */
! #ifdef IN_LIBGCC2
  #include <s390/fixdfdi.h>
  #endif
  
--- 24,30 ----
  
  /* Override the __fixdfdi etc. routines when building libgcc2.
     ??? This should be done in a cleaner way ...  */
! #if defined (IN_LIBGCC2) && !defined (__s390x__)
  #include <s390/fixdfdi.h>
  #endif
  
*************** extern int target_flags;
*** 94,99 ****
--- 94,110 ----
  #define CAN_DEBUG_WITHOUT_FP
  
  
+ /* In libgcc2, determine target settings as compile-time constants.  */
+ #ifdef IN_LIBGCC2
+ #undef TARGET_64BIT
+ #ifdef __s390x__
+ #define TARGET_64BIT 1
+ #else
+ #define TARGET_64BIT 0
+ #endif
+ #endif
+ 
+ 
  /* Target machine storage layout.  */
  
  /* Everything is big-endian.  */
*************** extern int target_flags;
*** 103,109 ****
--- 114,122 ----
  
  /* Width of a word, in units (bytes).  */
  #define UNITS_PER_WORD (TARGET_64BIT ? 8 : 4)
+ #ifndef IN_LIBGCC2
  #define MIN_UNITS_PER_WORD 4
+ #endif
  #define MAX_BITS_PER_WORD 64
  
  /* Function arguments and return values are promoted to word size.  */

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Richard Henderson wrote:
> On Fri, Mar 21, 2003 at 02:15:36AM +0100, Ulrich Weigand wrote:
> > Well, but we don't need the size in bits when computing stack
> > alignment.
> 
> True.  Perhaps you can find out why we're doing this?

OK, what happens here is that Ada passes to expand_decl a tree
describing this dynamically sized variable which has this as
'size' (i.e. size in bits) expression:

 <mult_expr 0x100002966c0
    type <integer_type 0x100001b7870 bit_size_type sizetype TI>
    arg 0 <ceil_div_expr 0x10000296680 type <integer_type 0x100001b7870 bit_size_type>
        arg 0 <mult_expr 0x10000296140 type <integer_type 0x100001b7870 bit_size_type>
            arg 0 <nop_expr 0x10000293eb0 type <integer_type 0x100001b7870 bit_size_type>
                arg 0 <non_lvalue_expr 0x10000293e88 type <integer_type 0x100001b7798 long int>
                    arg 0 <max_expr 0x10000295d80 type <integer_type 0x100001b7798 long int>
                        arg 0 <nop_expr 0x10000293c08 type <integer_type 0x100001b7798 long int>
                            readonly arg 0 <var_decl 0x10000290438 R1b>>
                        arg 1 <integer_cst 0x100001b8240 constant 0>>>>
            arg 1 <integer_cst 0x100001b8400 constant 8>>
        arg 1 <integer_cst 0x100001b8040 constant 64>> 
    arg 1 <integer_cst 0x100001b8040 64>>

and this even more complex tree as 'unit size' (size in bytes):

 <mult_expr 0x10000296740
    type <integer_type 0x100001b7798 long int sizetype DI>
    arg 0 <ceil_div_expr 0x10000296700 type <integer_type 0x100001b7798 long int>
        arg 0 <nop_expr 0x10000298230 type <integer_type 0x100001b7798 long int>
            arg 0 <exact_div_expr 0x10000296440 type <integer_type 0x100001b7870 bit_size_type>
                arg 0 <mult_expr 0x10000296140 type <integer_type 0x100001b7870 bit_size_type>
                    arg 0 <nop_expr 0x10000293eb0 type <integer_type 0x100001b7870 bit_size_type>
                        arg 0 <non_lvalue_expr 0x10000293e88 type <integer_type 0x100001b7798 long int>
                            arg 0 <max_expr 0x10000295d80>>>
                    arg 1 <integer_cst 0x100001b8400 constant 8>> 
                arg 1 <integer_cst 0x100001b8400 8>>>
        arg 1 <integer_cst 0x100001b80c0 constant 8>> 
    arg 1 <integer_cst 0x100001b80c0 8>>

expand_decl then passes this tree to expand_expr in order to compute 
the size needed for the variable (which is then passed on to 
allocate_dynamic_stack_space).

expand_expr now goes through this tree and creates a whole bunch
of RTL expressing all that stuff, including conversions between
DImode and TImode and the various divisions and multiplications.
The resulting RTL is then so complex that it won't get optimized
away by the RTL optimizers.

It would appear that at some stage in the process this expression
could be simplified to avoid use of TImode operations, but I'm not
familiar enough with the front-end parts to decide where ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Janis Johnson wrote:

>You can change the value of MIN_UNITS_PER_WORD when compiling libgcc2.c.

Thanks for the tip, this was indeed the problem.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Richard Kenner]

There is a bug I found a while ago related to unnecessary bitsizetype
operations, but I'm having troubloe setting up an environment
to test it.  In any case, I'm away until Wednesday morning.  More then.

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Richard Kenner]

Sorry I forgot to get back to this when I got back last week.

    What appears to happen is that the Ada source in question defines a
    variable-sized object with non-standard alignment requirements, and
    Ada reflects this by building a DECL_SIZE_UNIT tree containing various
    mult_expr and div_expr nodes.  As alignment is counted in bits, those
    have type bit_size_type, which on 64-bit platforms corresponds to
    TImode. When expanding that tree, the backend emits calls to __divti3.

The point of having separate DECL_SIZE_UNIT and DECL_SIZE is precisely for
the former to only have computations in sizetype and the latter in bitsizetype.
There are very rare situations where a bitsizetype might be in the expression
for DECL_SIZE_UNIT, but other occurrences are a bug.  Indeed, there's
a trivial bug in layout_decl that would account for some of those usages.
Here's the diff; I'll do the testing and installation for it within the
next few days.

*************** layout_decl (decl, known_align)
*** 368,372 ****
        DECL_SIZE_UNIT (decl) = TYPE_SIZE_UNIT (type);
      }
!   else
      DECL_SIZE_UNIT (decl)
        = convert (sizetype, size_binop (CEIL_DIV_EXPR, DECL_SIZE (decl),
--- 365,369 ----
        DECL_SIZE_UNIT (decl) = TYPE_SIZE_UNIT (type);
      }
!   else if (DECL_SIZE_UNIT (decl) == 0)
      DECL_SIZE_UNIT (decl)
        = convert (sizetype, size_binop (CEIL_DIV_EXPR, DECL_SIZE (decl),


    - does bit_size_type really need to be TImode

Perhaps not, but it should for consistency.  In practice, not that much needs
to be computed dynamically for bitsizes.

    - if so, shouldn't these special cases be implemented more efficiently
      somewhere (we divide by an integer constant 8 here)

No.

    - in general, are we really supposed to need TImode division

Yes.

    How does this work on other 64-bit platforms?

By having __divti3.

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Richard Kenner wrote:

>The point of having separate DECL_SIZE_UNIT and DECL_SIZE is precisely for
>the former to only have computations in sizetype and the latter in
bitsizetype.
>There are very rare situations where a bitsizetype might be in the
expression
>for DECL_SIZE_UNIT, but other occurrences are a bug.

I've just tried to reproduce the problem with my test case, and it does not
occur with current 3.3 (or head) any more.  Apparently the problem was
caused
by a failure of fold-const.c optimize out the redundant bitsizetype
operations,
which was fixed by rth's 2003-03-20 checkin:

http://gcc.gnu.org/ml/gcc-cvs/2003-03/msg01077.html

(Reverting that checkin causes the problem to reappear.)

In any case, I can now build a 64-bit gnat1 binary that contains no
reference to __divti3 whatsoever.


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

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Richard Kenner]

    In any case, I can now build a 64-bit gnat1 binary that contains no
    reference to __divti3 whatsoever.

But you still must have it, since you can easily construct programs that
will need it.

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Richard Kenner]

    I still don't quite understand under what circumstances you would in
    fact need to perform TImode computations at run time (that cannot be
    optimized away at compile time).  Do you have an example?

Somewhat contrived, but try:

procedure foo (x : integer) is
    type r1(d: integer) is record
      f1: string (1..d);
      f2: integer;
    end record;

    rr1: r1 (x);
    rr2: r1 (x * 2);
begin
    if rr1'size > rr2'size then
      raise program_error;
    end if;
end foo;

This has *some* TImode computations, but not many.

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Richard Kenner wrote:

>>In any case, I can now build a 64-bit gnat1 binary that contains no
>>reference to __divti3 whatsoever.

>But you still must have it, since you can easily construct programs that
>will need it.

I've fixed the incorrect libgcc build on s390x now, do I do have TImode
operations including __divti3.

I still don't quite understand under what circumstances you would in
fact need to perform TImode computations at run time (that cannot be
optimized away at compile time).  Do you have an example?


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

Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3

[Ulrich Weigand]

Richard Kenner wrote:

>This has *some* TImode computations, but not many.

Ah, I see, thanks.  In this case, everything could be expanded
inline (without requiring libgcc calls); that's probably why I
didn't notice before ...


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