lto gimple types and debug info

[Chris Lattner]

>> 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?

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 :)

-Chris