This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Lazy allocation of DECL_ASSEMBLER_NAME
- From: Chris Lattner <sabre at nondot dot org>
- To: Mark Mitchell <mark at codesourcery dot com>,Geoff Keating <geoffk at desire dot geoffk dot org>, <zack at codesourcery dot com>,<dalej at apple dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 1 Mar 2004 16:23:27 -0600 (CST)
- Subject: Re: Lazy allocation of DECL_ASSEMBLER_NAME
Mark Mitchell wrote:
> There are lots of things that are hard about inter-module analysis, as
> you of course know. :-) It's an inherent design problem: we're
> essentially trying to combine multiple C translation units into a single
> C translation unit, and C is not a language that permits that. Most
> object file formats are designed to support C, so we see these problems
> at that level too.
Just to be clear, this is not a problem with IMA, this is a problem with
doing it at the source level. C is just a really ugly language and never
really defined what happens if two structs or other declarations don't
agree.
In LLVM we address this by doing IPO on a non-source-level representation,
which fixes the issue, but since LLVM is a type-safe representation, our
linker has to be able to handle cases where you are linking two things
with different types. In the case of LLVM, the semantics are clearly
defined so this isn't a problem, it just took implementation. FWIW, this
was aluded to in my GCC summit paper (sec 4.4).
In GCC, perhaps the best way to do it is to make the IMA and normal
optimizer not depend on the source-level types as much as possible, they
simply cannot be trusted. Silently breaking the program is obviously a
bad alternative.
> In the example that you give, the program is not conforming if the
> definitions of "struct foo" are not identical across translation units.
> (Or, at least, that would be true in ISO C++. It might not have to be
> true in ISO C. You may know more than I.) In any case, if the structures
> do not match up across the translation units, we should just not combine
> them. That is certainly not the common case.
This comes up all of the time in real-world programs. zlib and 300.twolf
are examples that spring to mind immediately. libstdc++ does some other
funky things declaring "std::cin" as an array of characters in one .o
file, etc. Unfortunately, though compiler venders might like to not
handle this, we _have to_. It's just not acceptable to base optimization
decisions on type-equality, unless there are conservative fallbacks.
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/