From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-43046-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9632 invoked by alias); 18 Dec 2001 11:49:48 -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 9611 invoked from network); 18 Dec 2001 11:49:47 -0000
Received: from unknown (HELO Nicole.fhm.edu) (213.7.84.250)
  by sources.redhat.com with SMTP; 18 Dec 2001 11:49:47 -0000
Received: from fhm.edu (unknown [10.23.201.7])
	by Nicole.fhm.edu (Postfix on SuSE Linux 7.2 (i386)) with ESMTP
	id C322E6E18; Tue, 18 Dec 2001 13:56:33 +0100 (CET)
Date: Tue, 18 Dec 2001 03:53:00 -0000
From: degger@fhm.edu
Reply-To: degger@fhm.edu
Subject: Analysis try (was: Re: rs6000: Trivial code generation stupidity)
To: dje@watson.ibm.com
Cc: gcc@gcc.gnu.org
In-Reply-To: <200112172120.QAA22932@makai.watson.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Message-Id: <20011218125633.C322E6E18@Nicole.fhm.edu>
X-SW-Source: 2001-12/txt/msg00982.txt.bz2

On 17 Dec, David Edelsohn wrote:

> 	Also, you can look at the output from intermediate passes and see
> where gcc-2.95 chose the output in the correct register while gcc-3.1
> introduces the extra copies.  Track down which phase in gcc-3.1 is not
> collapsing the register copies or why it is introducing register
> copies.

You asked for it but be warned that this is the first time I try to
really analyse RTL and thus my analysis could be completely bogus and/or
wrong.

Consider:
int 
foo (int a, int b)
{
  return b+1;
}

gcc 3.1 produces:
foo:
        addi 4,4,1       # 15   *addsi3_internal1/2     [length = 4]
        mr 3,4   # 24   *movsi_internal1/1      [length = 4]
        blr      # 36   *return_internal_si     [length = 4]

Here we can see that the register move comes from insn 24.
Analysing the RTL of all passes between gcc 2.95.3 and gcc 3.1 shows
that in the combine pass gcc 2.95.3 merges the plus:SI and the move
into 
(insn 14 12 15 (set (reg/i:SI 3 r3)
        (plus:SI (reg:SI 4 r4)
            (const_int 1 [0x1]))) 52 {*addsi3_internal1} (nil)
    (expr_list:REG_DEAD (reg:SI 4 r4)
        (nil)))

while gcc 3.1 keeps them in seperate insns using a virtual register for
the result of the plus:SI:
(insn 15 7 20 (set (reg:SI 118)
        (plus:SI (reg/v:SI 117)
            (const_int 1 [0x1]))) 36 {*addsi3_internal1} (insn_list 6 (nil))
    (expr_list:REG_DEAD (reg/v:SI 117)
        (nil)))

(insn 24 20 27 (set (reg/i:SI 3 r3)
        (reg:SI 118)) 295 {*movsi_internal1} (insn_list 15 (nil))
    (expr_list:REG_DEAD (reg:SI 118)
        (nil)))

So it seems that combine broke because it fails to recognize the
opportunity to get rid of a virtual register.

The bottom lines of the combine pass outputs are
2.95.3:
;; Combiner totals: 3 attempts, 3 substitutions (0 requiring new space),
;; 2 successes.

3.1:
;; Combiner totals: 0 attempts, 0 substitutions (0 requiring new space),
;; 0 successes.

If anyone wants to see the outputs of the intermediate passes feel free
to contact me and you'll get them.

--
Servus,
       Daniel