TRANSLATION_UNIT_DECL breaks bootstrap

[Daniel Berlin]

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.


>