This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: lto gimple types and debug info
- From: Chris Lattner <clattner at apple dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, GCC Development <gcc at gcc dot gnu dot org>, Diego Novillo <dnovillo at google dot com>, "Hubicha, Jan" <jh at suse dot cz>, Richard Guenther <richard dot guenther at gmail dot com>, "Taylor, Ian Lance" <iant at google dot com>, Ollie Wild <aaw at google dot com>, "Maddox, Bill" <maddox at google dot com>, jason at redhat dot com, Rafael Espindola <espindola at google dot com>
- Date: Thu, 24 Jul 2008 22:01:22 -0700
- Subject: Re: lto gimple types and debug info
- References: <4888AD1F.7080007@naturalbridge.com> <42A72A32-8501-4CFC-971C-4859955F413A@apple.com> <4888B8F0.9080008@naturalbridge.com> <52520C8B-6074-4010-BFB7-4E906CADCAC6@apple.com> <4aca3dc20807241433oabfe46w7b78ccac8e7fd2c1@mail.gmail.com> <4888FAAB.6090005@naturalbridge.com>
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