This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Trust TREE_ADDRESSABLE
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches at gcc dot gnu dot org, Richard Biener <richard dot guenther at gmail dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>
- Date: Thu, 12 Jun 2014 11:16:31 +0200 (CEST)
- Subject: Re: [PATCH] Trust TREE_ADDRESSABLE
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1406041546210 dot 2632 at zhemvz dot fhfr dot qr> <10094132 dot LNpDJNWIDH at polaris> <20140611194324 dot GB21180 at kam dot mff dot cuni dot cz> <2989577 dot lx1lXJASQA at polaris> <alpine dot LSU dot 2 dot 11 dot 1406121017580 dot 32404 at zhemvz dot fhfr dot qr> <20140612085009 dot GB6864 at kam dot mff dot cuni dot cz>
On Thu, 12 Jun 2014, Jan Hubicka wrote:
> > On Thu, 12 Jun 2014, Eric Botcazou wrote:
> >
> > > > If we want to give frontends a way to pass information that address of a
> > > > given global object is not taken (apparently useful for Ada and its alias
> > > > attribute), then I do not think we are looking for middle-end only
> > > > solution.
> > >
> > > I don't feel very confortable with doing that in Ada, since everybody seems to
> > > be thinking that TRE_PUBLIC/DECL_EXTERNAL objects are implicitly addressable
> > > (see for example Steven's reasoning in an earlier message).
> > >
> > > > If we really do not want to revisit TREE_ADDRESSABLE in frontends, we can do
> > > > the following:
> > > > 1) change semantics of addressable flag on global variables in a way
> > > > Richard did, document it is initialized only after symbol table is built 2)
> > > > add code to cgraph construction to set TREE_ADDRESSABLE on every global
> > > > variable it sees.
> > > > IPA visibility is run before early optimizations. I suppose we can set
> > > > it there. I.e. in function_and_variable_visibility whenever we set
> > > > externally_visible and we have !in_lto_p
> > > > It is bit of hack.
> > > > 3) perhaps add some way to avoid 2) on objects we want - apparenlty we now
> > > > have DECL_NONALIASED that may be useful for this.
> > >
> > > Then how about using DECL_NONALIASED instead of TREE_ADDRESSABLE to achieve
> > > the initial goal here? That is to say, may_be_aliased tests DECL_NONALIASED
> > > for TREE_PUBLIC/DECL_EXTERNAL DECLs and the LTO front-end sets it properly.
> >
> > Btw, may_be_aliased already does that. So yes, when LTO promotes sth
> > from non-public to public but hidden visibility and TREE_ADDRESSABLE
> > was not set it could set DECL_NONALIASED. That would at least preserve
> > the aliasing behavior from without using LTO. If the resolution info
> > from the linker allows us to make initial public variables hidden
> > _and_ some LTO IPA pass proves that the variables address is not taken
> > then that pass can set DECL_NONALIASED as well.
>
> Yep, I suppose each time I clear TREE_ADDRESSABLE flag, i can also set
> DECL_NONALIASED.
> >
> > Of course one issue is that it's impossible to write a verifier that
> > checks whether DECL_NONALIASED and TREE_ADDRESSABLE are "out-of-sync"
> > (because by design they can be). So it's a bit more fragile
> > (we could make the operand scanner that "updates" TREE_ADDRESSABLE
> > also unset DECL_NONALIASED of course).
>
> Hmm,when one would unset it?
When you extract the address and use it. For example when you
do auto-parallelization and outline a part of your function it
passes arrays as addresses.
Or if you start to introduce address induction variables like
the vectorizer or IVOPTs does.
Richard.