This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fortran aliasing in tree-ssa-alias.c (may_alias_p).
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Cc: Diego Novillo <dnovillo at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 19 Mar 2006 09:05:57 -0500
- Subject: Re: Fortran aliasing in tree-ssa-alias.c (may_alias_p).
- References: <4412C7C6.3020504@moene.indiv.nluug.nl> <16728322.1142087744409.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net> <441D3CF1.2070704@moene.indiv.nluug.nl>
On Sun, 2006-03-19 at 12:13 +0100, Toon Moene wrote:
> Diego Novillo wrote:
>
> > On 03/11/06 07:51, Toon Moene wrote:
>
> >> * tree-ssa-alias.c (may_alias_p): if -fargument-noalias-global > 1,
> >> a pointer argument may not point to anything else.
>
> > Well, that's not what the documentation states. The pointer could be
> > made to point to a local stack variable in the body of the function. I
> > realize that this may not happen in Fortran, but we are in a
> > language-independent region of the code here.
> >
> > I would propose adding flag_argument_noalias == 3 to convey what Fortran
> > guarantees: Pointer arguments that cannot point to globals nor locals.
> > Then you can do:
> >
> > ! /* If -fargument-noalias-global is > 2, pointer arguments may
> > ! not point to anything else. */
> > ! if (flag_argument_noalias > 2 && TREE_CODE (ptr) == PARM_DECL)
> >
> > Not only here, but in other parts of alias.c.
>
> OK, the attached patch is what I came up with.
>
> There are two places where I left tests on flag_argument_noalias alone:
> in alias.c and emit-rtl.c. I believe they are still correct as coded.
>
> I tested this patch by a bootstrap (C and Fortran only), make -k
> check-fortran and a 9-cycle run of HIRLAM on x86_64-unknown-linux-gnu.
>
> Of course, I'll do a complete bootstrap/make -k check on approval, but
> AFAICS, no other front end sets flag_argument_noalias.
>
> Is this OK for mainline ?
This is fine.
BTW, I *imagine* there are probably some places in the pruning we do in
tree-ssa-operands.c that you can use this information as well.
See access_can_touch_variable in tree-ssa-operands.c.
I know this seems like a lot of places to have to touch, but the other
places are really trying to figure out an exact points-to set for the
variable. If they fail for some reason, we are going to fall back to
type based information, and this pruning will be useful.