From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-181839-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10224 invoked by alias); 3 Feb 2014 10:36:22 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
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 10214 invoked by uid 89); 3 Feb 2014 10:36:22 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: mx2.suse.de
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 03 Feb 2014 10:36:20 +0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 5CF28AC56;	Mon,  3 Feb 2014 10:36:17 +0000 (UTC)
Date: Mon, 03 Feb 2014 10:36:00 -0000
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
cc: Bingfeng Mei <bmei@broadcom.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: No TBAA before ptr_derefs_may_alias_p?
In-Reply-To: <alpine.LSU.2.11.1402031104520.29326@zhemvz.fhfr.qr>
Message-ID: <alpine.LSU.2.11.1402031133100.29326@zhemvz.fhfr.qr>
References: <B71DF1153024A14EABB94E39368E44A604269C31@SJEXCHMB13.corp.ad.broadcom.com> <52EBC010.5030409@suse.de> <B71DF1153024A14EABB94E39368E44A604269DAC@SJEXCHMB13.corp.ad.broadcom.com> <783352a3-eb4d-467a-82bd-8cca90f74a30@email.android.com> <B71DF1153024A14EABB94E39368E44A60427497B@SJEXCHMB13.corp.ad.broadcom.com> <20140203095938.GF892@tucnak.redhat.com> <alpine.LSU.2.11.1402031104520.29326@zhemvz.fhfr.qr>
User-Agent: Alpine 2.11 (LSU 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SW-Source: 2014-02/txt/msg00017.txt.bz2

On Mon, 3 Feb 2014, Richard Biener wrote:

> And note that for the case in question we
> can derive non-aliasing because with
> 
>   p[i] += q[i];
> 
> p[i] is both read _and_ written in the same iteration thus
> it cannot have the dynamic type of q[i] before it's stored
> into.  Of course data-dependence doesn't do this kind of
> analysis currently, but it certainly could.

The vectorizer already has code to analyzes data-refs for groups,
not for read-write of the same loc as needed here, so it could
be reasonably easy to extend its analysis to detect this case
and mark the write DR with a flag so that in
vect_analyze_data_ref_dependence the _vectorizer_ could apply
TBAA to disambiguate the two DRs.

Richard.