This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Trust TREE_ADDRESSABLE


> 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?

Honza
> 
> Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]