From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-70797-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30009 invoked by alias); 21 Mar 2003 19:44:41 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 29680 invoked from network); 21 Mar 2003 19:44:29 -0000
Received: from unknown (HELO faui11.informatik.uni-erlangen.de) (131.188.31.2)
  by sources.redhat.com with SMTP; 21 Mar 2003 19:44:29 -0000
Received: (from weigand@localhost)
	by faui11.informatik.uni-erlangen.de (8.9.1/8.1.4-FAU) id UAA16040; Fri, 21 Mar 2003 20:44:26 +0100 (MET)
From: Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de>
Message-Id: <200303211944.UAA16040@faui11.informatik.uni-erlangen.de>
Subject: Re: RFA: Ada variable-sized objects, bit_size_type == TImode, and divti3
To: rth@redhat.com (Richard Henderson)
Date: Fri, 21 Mar 2003 20:25:00 -0000
Cc: weigand@immd1.informatik.uni-erlangen.de (Ulrich Weigand), gcc@gcc.gnu.org,
        uweigand@de.ibm.com
In-Reply-To: <20030321071015.GA7800@redhat.com> from "Richard Henderson" at Mar 20, 2003 11:10:15 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-03/txt/msg01380.txt.bz2

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