Re: lto gimple types and debug info

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Daniel Berlin wrote:
> On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <clattner@apple.com> wrote:
>   
> > On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
> >     
> > > > I thought the whole idea of the LTO project was to keep as much language
> > > > specific type information as late as possible.  If you start stripping out
> > > > useful information about types, it becomes harder to do high level
> > > > optimizations like devirtualization and other source-specific
> > > > transformations.  This is one of the major advantages of LTO, no?
> > > >
> > > >         
> > > I think that there is a lot of front end information in the types that
> > > really is not useful to the middle ends.   That can be stripped away.  I
> > > certainly do not want to strip anything that could be used for something
> > > like devirtualization.
> > > As a (possibly flawed example), the private attribute in c++ is completely
> > > useless for optimization because it is legal for functions that otherwise
> > > have no access to a private field to gain access by pointer arithmetic.
> > >  However, in a truly strongly typed language, the private attribute can be
> > > used to limit the scope of a variable to a single compilation unit.
> > >       
> > Ok, but how do you decide whether something is important or not to keep?
> >  Why go through the work of removing the information if you may need it
> > later?  How much will you really be able to take out?  Is this about
> > removing a bit here and a bit there, or is there a large volume of the info
> > that can be removed?
> >     
>
> I dunno, this seems like a thing you could better figure out by trying
> it and seeing where the problems are than by trying to anticipate
> every single possible problem
> (not that there should be no design, but that it would be better to
> start with a design and iterate it than try to figure out perfect
> ahead of time).
>   
I agree that it is pointless to go thru the information bit by bit.  On 
the other hand there may be other things like the typedefs that serve no 
purpose in the middle end but do take a lot of space and require time to 
traverse. 

However, at some point we are going to have to get down to the 
discussion of what it means for two types declared in two different 
compilation units to be "the same"  and the less baggage that we have 
dragged in that is not relevant to that decision, the less unpleasant 
that process will be.


> > -Chris
> >
> >