Re: lto gimple types and debug info

["Richard Guenther" <richard dot guenther at gmail dot com>]

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

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

Richard.