> 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
