This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TRANSLATION_UNIT_DECL breaks bootstrap
On Sunday, July 13, 2003, at 12:11 AM, Geoff Keating wrote:
Daniel Berlin <dberlin@dberlin.org> writes:
whereas the "true" globals are clobbered on any call anywhere.
To do this, we need to distinguish between those variables local to
a
file, and those that aren't.
HAS_FILE_SCOPE_P would do this.
This all seems like it needs to be a langhook.
No, we aren't doing this on language specific trees, no langhook
should be necessary or is wanted.
You're making assumptions about what the language allows users to do
or not do, and there's no reason that the language should have any
particular restriction.
Once again:
We don't deal with language specific trees, or a language specific IR.
Thus, whatever the heck the language wants to do is fine by me, i just
don't see it at the level we work at.
I shouldn't need to query the language at this level, since we never
see language-specific constructs.
How does this work in
C++, to handle (for instance) private static variables in classes?
It works just fine.
So you can tell that the variable can be changed only by methods of
that class?
Assuming we did interprocedural analysis on these methods (we only do
interprocedural analysis on calls to static functions), yes, we could
theoretically determine this.
Though it would be a bit of work to extract the information.
You've seemed to miss the point of points-to analysis.
It's not to determine what variables are accessible from where, it's to
determine what variables point to which other variables (by point to,
we mean that given a pointer, what variables could be accessed by
dereferencing it, by load or by store).
These are different tasks.
Points-to analysis produces points-to sets, given a function (or
functions).
This is a list of variables a pointer variable may point to (be they
pointer variables or non-pointer variables). Not a list of class
members, or anything like that.
In other words, in the following function, it can tell you:
What possible variables *a = 5 could change.
What possible variables e = *a could reference.
etc
int main(void)
{
int *a;
int *b;
int *c;
int d;
int e;
b = &d;
a = b;
c = &e;
b = c;
}
In this particular case, we end up with the sets:
b :={d,e}(2)
d :={}(0)
a :={d,e}(2)
c :={e}(1)
e :={}(0)
Meaning that *a and *b could really be d or e, *c could really be e.
I'm not going to get into the whole description of how function calls
and fields and global variables whatnot are handled in intra- or
inter-procedural points-to analysis, as this is detailed quite well in
the billion and a half papers on various forms of points-to analysis
one can find. Suffice to say, you can do it in non-language specific
ways at the cost of some accuracy, which is what i've done.
What do you do with the information?
Use it to optimize better in tree-ssa.
Do
you look at DECL_CONTEXT for that?
Right now, we aren't field based (IE accesses to a field of a variable
are globbed to the entire variable), to avoid dealing with this.
That can't be right. You mean that if someone writes
struct foo {
static int x;
int y;
};
{
foo a, b;
b.x = 3;
a.x = 2;
printf ("%d\n", b.x);
}
you associate the 'a.x' with 'a' and then assume it doesn't change
'b.x', and print 3 instead of 2?
Errr, a and b don't points to anything here, there aren't any pointers
in this function. I was referring to globbing pointer to structure
field accesses of a variable together for the purposes of points-to,
which is a well-known and well tested method, but loses accuracy,
because we give a possible superset of the variables that could
actually be accessed.
Here we would say that "b" and "a" point-to no other variable, which is
correct.
I urge you to read up on the point of points-to analysis, and how it
generally works.