This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: No TBAA before ptr_derefs_may_alias_p?
- From: Bingfeng Mei <bmei at broadcom dot com>
- To: Richard Biener <rguenther at suse dot de>, Jakub Jelinek <jakub at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 3 Feb 2014 11:58:52 +0000
- Subject: RE: No TBAA before ptr_derefs_may_alias_p?
- Authentication-results: sourceware.org; auth=none
- References: <B71DF1153024A14EABB94E39368E44A604269C31 at SJEXCHMB13 dot corp dot ad dot broadcom dot com> <52EBC010 dot 5030409 at suse dot de> <B71DF1153024A14EABB94E39368E44A604269DAC at SJEXCHMB13 dot corp dot ad dot broadcom dot com> <783352a3-eb4d-467a-82bd-8cca90f74a30 at email dot android dot com> <B71DF1153024A14EABB94E39368E44A60427497B at SJEXCHMB13 dot corp dot ad dot broadcom dot com> <20140203095938 dot GF892 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1402031104520 dot 29326 at zhemvz dot fhfr dot qr> <alpine dot LSU dot 2 dot 11 dot 1402031133100 dot 29326 at zhemvz dot fhfr dot qr>
Even I change acc[i] += to acc[i] in the original example,
gcc still generates versioning due to alias. So it clearly
behave differently from scalar code aliasing analysis.
tst3.c:12: note: versioning for alias required: can't determine dependence between _10->real and *_7
tst3.c:12: note: mark for run-time aliasing test between _10->real and *_7
tst3.c:12: note: versioning for alias required: can't determine dependence
Bingfeng
-----Original Message-----
From: Richard Biener [mailto:rguenther@suse.de]
Sent: 03 February 2014 10:35
To: Jakub Jelinek
Cc: Bingfeng Mei; gcc@gcc.gnu.org
Subject: Re: No TBAA before ptr_derefs_may_alias_p?
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.