From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-306675-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 26791 invoked by alias); 4 Nov 2011 14:02:50 -0000
Received: (qmail 26722 invoked by uid 22791); 4 Nov 2011 14:02:49 -0000
X-SWARE-Spam-Status: No, hits=-3.6 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_TM
X-Spam-Check-By: sourceware.org
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Nov 2011 14:02:35 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2])	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))	(No client certificate requested)	by mx2.suse.de (Postfix) with ESMTP id D5C358D40D;	Fri,  4 Nov 2011 15:02:33 +0100 (CET)
Date: Fri, 04 Nov 2011 14:09:00 -0000
From: Michael Matz <matz@suse.de>
To: Richard Guenther <rguenther@suse.de>
Cc: Jakub Jelinek <jakub@redhat.com>,	Ira Rosen <ira.rosen@linaro.org>, Richard Henderson <rth@redhat.com>,	gcc-patches@gcc.gnu.org
Subject: Re: Patch ping
In-Reply-To: <alpine.LNX.2.00.1111041219460.26779@zhemvz.fhfr.qr>
Message-ID: <Pine.LNX.4.64.1111041453480.30317@wotan.suse.de>
References: <20111102201829.GT1052@tyan-ft48-01.lab.bos.redhat.com> <alpine.LNX.2.00.1111041043570.26779@zhemvz.fhfr.qr> <20111104102525.GH1052@tyan-ft48-01.lab.bos.redhat.com> <alpine.LNX.2.00.1111041219460.26779@zhemvz.fhfr.qr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-11/txt/msg00565.txt.bz2

Hi,

On Fri, 4 Nov 2011, Richard Guenther wrote:

> > With the approach the incremental patch does I just walk what 
> > split_constant_offset during DR walks and peel off loop invariants 
> > until I have something that should be used as the vectorized index.
> 
> It looks like split_constant_offset walks def stmts in an unbound 
> fashion.  That's surely a bad idea - SCEV should already have expanded 
> everything non-loop-invariant, thus it should at most look through DEFs 
> that trivially add to the constant offset, not through others.

split_constant_offset is also used for canonicalization, to increase 
chances of finding the same base in two data refs to be able to use offset 
based disambiguation.  For that it sometimes has to look also through loop 
invariant parts.


Ciao,
Michael.