This is the mail archive of the
mailing list for the GCC project.
Re: LLVM/GCC Integration Proposal
- From: Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Chris Lattner <clattner at apple dot com>
- Date: Sat, 19 Nov 2005 15:20:39 -0500 (EST)
- Subject: Re: LLVM/GCC Integration Proposal
- Reply-to: Kenneth dot Zadeck at NaturalBridge dot com
> Specifically, advocates of the recent link-time-optimization proposal
>  may claim that exposing all of the information that DWARF captures
> (e.g. about the type system) at link-time is a good thing: it makes it
> easier to do specific high-level optimizations, because all of the
> information is trivially available. However, they are ignoring the
> issue of handling multiple languages at the same time: an optimizer
> with this design has to be aware of (and be able to update) all
> possible source-language information and must be extended in the
> future as new languages are added (this is the problem with universal
> compilers, dating back to the UNCOL design). Also, the linker needs to
> know how to combine declarations defined in different languages,
> because an interprocedural optimizer only want to see one declaration
> for each logical variable (for example). This quickly becomes
> difficult and messy, which is presumably why the link-time proposal
> allows the linker to "give up" linking two translation units.
The reason for the complexity of the type system handling in our
proposal was motivated primarily by two concerns:
1) We need to keep track of the types so that they are available for
debugging. As LLVM does not support debuggers at this point, it
may be difficult to see through all of the issues required to keep
track of the information while still doing good optimization.
In the end we will have to produce a set of debugging info for the
optimized program, loosing all the type information before you
start did not seem the correct plan.
2) GCC has a very large user community that knows nothing about
compilers except how to shepherd their programs through GCC and
run the result. Unless I am mistaken about the LLVM, it has no
such user community. I personally cannot guarantee that GCC (or
for that matter any optimizing compiler) can correctly cross inline
and compile a program if the types in one module are not consistent
with the types in another module. Just because the program
happens to work correctly when separately compiled is not enough.
When Mark and I started working on this proposal (and later the
rest of the volunteers) we decided that this was not going to be
either an academic exercise or just something to run benchmarks.
What that means to me is that the link time optimizer needs to be
able to either generate correct code or give up in some predictable
manner. Having the compiler push forward and hope everything
turns out OK is not enough. Discretion is the better part
I think that taking advantage of mixed C, C++ or C and Fortran
programs is going to be hard. But it is what the GCC customers want
and there is a desire to accommodate them if possible.
On the positive side, LLVM has a lot more experience in managing whole
program compilation, and it is a much cleaner software base. It would
be a good to find some mechanism to take advantage of that experience.
Trying to make the hippo dance is not really a lot of fun.