This is the mail archive of the gcc@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: What tree flags tell me a variable is local?


> X-Original-To: geoffk@foam.wonderslug.com
> Date: Sat, 14 Jun 2003 16:06:10 -0400
> Cc: gcc@gcc.gnu.org
> From: Daniel Berlin <dberlin@dberlin.org>
> X-OriginalArrivalTime: 14 Jun 2003 20:05:57.0812 (UTC) FILETIME=[5E882740:01C332B0]
> 
> 
> On Saturday, June 14, 2003, at 03:09  PM, Geoff Keating wrote:
> 
> > Daniel Berlin <dberlin@dberlin.org> writes:
> >
> >> I know you can do it with decl_function_context, but I'm trying to
> >> avoid using it, because it's too expensive in PTA due to call overhead
> >> (Any time a query is made, we need to figure out whether they are
> >> querying about a global or not, so we end up calling it millions of
> >> times).
> >>
> >> Thus, i'm wondering if there is some combination of tree flags i can
> >> rely on to always be correct.
> >>
> >> Currently, I check DECL_CONTEXT, and iff it's a FUNCTION_DECL, we say
> >> it's local, otherwise, we call decl_function_context and see if it
> >> returns NULL.
> >>
> >>
> >> Is there a better way?
> >
> > I presume that by 'local' you mean 'inside a function scope', not
> > 'file-local' or 'automatic'?
> 
> Right. More "local to a function" (IE extern variables declared extern 
> inside a function aren't function-local in this sense)
> 
> >
> > No, there's no better way.
> 
> > Why do you want to do this?
> Because Points-to, and tree-ssa in general, currently globs all 
> non-local variables to one variable named "GLOBAL_VAR", which is 
> clobbered by most types of function calls.
> 
> Thus, to do Points-To Analysis properly (IE be able to say what 
> points-to GLOBAL_VAR) , we need to differentiate between function 
> locals and non-locals.

OK.  To be precise, you want to know if a particular variable can't be
referenced outside this function, correct?

In that case, for C I'd suggest

! (DECL_EXTERNAL (decl) && ! DECL_STATIC (decl)
&& (! DECL_STATIC (decl) || decl_function_context (decl) == NULL)

but note that this is language-specific.  It is probably good for C++
too.

That should cut down the amount of inspection of the DECL_CONTEXT
significantly.

I'm assuming in that the points-to analysis can properly deal with
nested functions, like

int foo(void) {
  static int x;
  int *bar(void) { return &x };
  ...
}

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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