This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What tree flags tell me a variable is local?
- From: Geoff Keating <geoffk at geoffk dot org>
- To: dberlin at dberlin dot org
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 14 Jun 2003 16:33:07 -0700
- Subject: Re: What tree flags tell me a variable is local?
- References: <A4247C54-9EA3-11D7-B5D8-000A95A34564@dberlin.org>
> 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>