Re: LLVM/GCC Integration Proposal

[Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>]

>  Specifically, advocates of the recent link-time-optimization proposal
>  [1] 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
   of valor.

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.


Kenny