This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Adjust the middle-end memory model
- From: Richard Guenther <rguenther at suse dot de>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 20 May 2009 10:26:54 +0200 (CEST)
- Subject: Re: [PATCH][RFC] Adjust the middle-end memory model
- References: <alpine.LNX.2.00.0905081221560.25789@zhemvz.fhfr.qr> <alpine.LNX.2.00.0905191620000.25789@zhemvz.fhfr.qr> <4A12F125.6030309@codesourcery.com>
On Tue, 19 May 2009, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> - The tree alias oracle got similar functionality, refs_anti_dependent
> >> and refs_output_dependent and the tree level data dependence
> >> analysis code makes use of these.
>
> Do we still use TBAA for the original motivating reason for adding it,
> e.g.,:
>
> void f(float *f, int *n) {
> for (int i = 0; i < *n; ++i) {
> f[i] *= 2;
> }
> }
>
> where here you want to know that "f[i]" does not modify "*n"?
>
> (Yes, that code is kinda hokey, in that real-world code would probably
> not pass n by-reference, but of course this happens with structures and
> such...)
Yes, for the purpose of hoisting the load of *n out of the loop (if
a store to f[i] would clobber *n then you wouldn't be allowed to read
it back as int). What matters for hoisting loads is whether there
is a true dependence between *n and f[i] which there is not, as we
still disambiguate using TBAA for true dependence queries.
The difference is if you want to sink a load from *n beyond the
store to f[i] - in which case you ask if there is an anti-dependence
which we cannot exclude in this case (no TBAA is allowed here).
The latter is to make placement new and friends work.
Richard.