From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-56853-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 587 invoked by alias); 21 Jul 2002 09:28:23 -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 570 invoked from network); 21 Jul 2002 09:28:21 -0000
Received: from unknown (HELO laptop.moene.indiv.nluug.nl) (195.109.255.217)
  by sources.redhat.com with SMTP; 21 Jul 2002 09:28:21 -0000
Received: from local ([127.0.0.1] helo=moene.indiv.nluug.nl)
	by laptop.moene.indiv.nluug.nl with esmtp (Exim 3.12 #1 (Debian))
	id 17WCwb-0000Lp-00; Sun, 21 Jul 2002 11:24:01 +0200
Message-ID: <3D3A7DB0.A134B3A6@moene.indiv.nluug.nl>
Date: Sun, 21 Jul 2002 10:01:00 -0000
From: Toon Moene <toon@moene.indiv.nluug.nl>
Organization: Moene Computational Physics, Maartensdijk, The Netherlands
X-Accept-Language: en
MIME-Version: 1.0
To: Richard Henderson <rth@redhat.com>
CC: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: Alias analysis - does base_alias_check still work ?
References: <3D346B28.47039CD9@moene.indiv.nluug.nl> <3D3824DA.B198DC39@moene.indiv.nluug.nl> <20020719095446.A15598@redhat.com> <3D38543D.F5D84797@moene.indiv.nluug.nl> <3D386E94.E6D03C8B@moene.indiv.nluug.nl> <20020719153514.B15706@redhat.com> <20020719170330.A15734@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-07/txt/msg00942.txt.bz2

Richard Henderson wrote:

> On Fri, Jul 19, 2002 at 03:35:14PM -0700, Richard Henderson wrote:

> > The remaining sts/lds pairs are writes then reads from SY.
> > We've lost track of the fact that the write is to index I
> > and the read from index I+1, and so cannot overlap.
> 
> This appears to be the unroller doing stupid things.  The attached
> patch1 should cure this.  If this patch can be shown to be a win,
> we can axe this section of code properly rather than goto out of it.

I combined your MEM_EXPR patch and patch1, but now I get (-O2
-funroll-loops -fno-rerun-loop-opt):

$L6:
        lds $f10,0($18)
        lds $f14,-4($5)
        lda $2,4($5)
        lda $3,8($5)
        lda $18,4($18)
        lda $4,12($5)
        lda $1,-3($7)
        lda $7,-4($7)
        lds $f11,0($18)
        addl $1,$31,$6
        lda $18,4($18)
        lds $f12,0($18)
        lda $18,4($18)
        muls $f15,$f10,$f10
        lds $f13,0($18)
        lda $18,4($18)
        muls $f15,$f11,$f11
        muls $f15,$f12,$f12
        adds $f14,$f10,$f14
        muls $f15,$f13,$f13
        sts $f14,-4($5)
        lda $5,16($5)
        lds $f10,-4($2)
        adds $f10,$f11,$f10
        sts $f10,-4($2)
        lds $f11,-4($3)
        adds $f11,$f12,$f11
        sts $f11,-4($3)
        lds $f10,-4($4)
        adds $f10,$f13,$f10
        sts $f10,-4($4)
        bge $6,$L6

which is worse than you showed for the MEM_EXPR patch alone 32 insns vs
27).

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)