Re: TRANSLATION_UNIT_DECL breaks bootstrap

[Daniel Berlin <dberlin at dberlin dot org>]

> > > Steven commented:
> > >
> > > > Maybe there should be a macro HAS_FILE_SCOPE in tree.h??
> >
> > As I was thinking about this a little further I was wondering why
> > DECL_CONTEXT should ever be NULL after this patch.  Why not just
> > _always_ put a TRANSLATION_UNIT_DECL in DECL_CONTEXT if the entity is
> > global, even if gcc is not doing intermodule stuff.
>
> I think I decided you don't want to do that if the declaration isn't
> static, and there was some good reason for it, but don't remember
> exactly.  Feel free to try it and tell me how it turns out :-).

> > > I haven't yet found a need for it.  I think file scope (or,
> > > technically, translation unit scope) is a language-specific
> > > concept---I can certainly imagine languages where it is
> > > meaningless---and so it probably shouldn't appear in the middle-end.
> > > Usually, you want TREE_PUBLIC or TREE_STATIC or DECL_EXTERNAL 
> > > instead.
> >
> > Well, we should define some semantics for this; after all, trees 
> > should
> > be language-independent for tree-ssa.
>
> I agree that we should define the meaning of TRANSLATION_UNIT_DECL, at
> least in some vague way ("like NAMESPACE_DECL, but doesn't have a
> name"), I just don't think that we need the particular predicate you
> suggested.  Could you give an example of how it would be used?

Let me give you an example.
I want to be able to determine, for intraprocedural points-to analysis, 
which variables are local to a function, which are truly global, and 
which are just local to some file (since we can now have multiple files 
in one compilation).
The points-to sets of all of these are different.
Before I only had to handle locals and non-local, because all 
non-locals were globbed to GLOBAL_VAR (in intraprocedural mode, you get 
no benefit from tracking each global's points-to set separately), and 
we did one file at a time, file-scope might as well equal global scope 
for points-to purposes, because anything file-local was accessible from 
any function we would see.

However, for multiple-file compilations (again, still doing 
intraprocedural points-to), we can do better if we know that certain 
variables are only accessible from certain functions (functions 
contained within the same TRANSLATION_UNIT_DECL or whatever), in that 
we don't have to clobber them on calls except in these functions, 
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.

--Dan