Re: TRANSLATION_UNIT_DECL breaks bootstrap

[Geoff Keating <geoffk at geoffk dot org>]

> X-Original-To: geoffk@foam.wonderslug.com
> Cc: s.bosscher@student.tudelft.nl, mark@codesourcery.com, gcc@gcc.gnu.org
> From: Daniel Berlin <dberlin@dberlin.org>
> Date: Sat, 12 Jul 2003 01:44:46 -0400
> X-OriginalArrivalTime: 12 Jul 2003 05:54:38.0359 (UTC) FILETIME=[145F2A70:01C3483A]
> 
> >
> >>> 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, 

Actually, that's not true, because the code could call some external
routine that then calls back into some routine in this file...

> 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.  How does this work in
C++, to handle (for instance) private static variables in classes?  Do
you look at DECL_CONTEXT for that?  How do you cope with friend
classes and subclasses?

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