Re: lto gimple types and debug info

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Richard Guenther wrote:
> On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <clattner@apple.com> wrote:
>   
> > > > 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.
> > >       
> > Sure, typedefs in C/C++ seem clearly useless.  I'm just curious how you plan
> > to go about deciding whether things are useless in a more general context.
> >  How fine of a granularity do you intend to inspect bits?  Trees have lots
> > of random stuff that are hard to identify and unify.  Hopefully this will be
> > a good step towards making LTO actually be able to work with source files
> > that come from different languages.  Does this mean that all
> > language-specific type info will be removed?
> >     
>
> Well, "removed" as in "transformed into bits of the common middle-end
> type system".  As we get new fancy optimizations that require
> more information we can easily add to the middle-end type-system.
>
> In this light my advocacy for (1) becomes obvious ;)
>
>   
Despite my bias towards (4), (1) really is a reasonable option.  We do 
not do these transformations except at high optimization levels, and the 
code at that point is mostly undebuggable anyway.
> > More generally, can you detail what your plan is?  Is it to remove specific
> > pieces (like typedefs, what else?) or just hack and slash random stuff if it
> > gets in your way?  I'm more curious about your approach and "threshold for
> > usefulness" than an abstract statement about how you will remove useless
> > stuff and keep the useful stuff :)
> >     
>
> The approach would be to add pieces to an "empty" middle-end
> type system, not to remove things from what the frontends give us.
> This way we don't even need to look at all the stuff that is in
> the frontends, but can concentrate on what is useful and needed
> for the middle-end right now.
>
>   
And if doing (4) means that the gimple type system is as fat as the 
front end one, then there will be no gimple type system. 

> Richard.
>