[LLVMdev] can bc/asm carry enough type info for C/C++ compiler/interpreter?

[Misha Brukman]

On Mon, Apr 25, 2005 at 04:34:07AM -0500, Zeyu  Chen wrote:
> I am asking this question to see if it is possible or desirable to
> build a compilation/runtime system for C/C++ that can support the
> following:
> 
> 1. allow bc to call native (in dynamically loaded *.so)

You can do this today, e.g., with lli -load=native.so file.bc

> 2. allow native to call bc (through JIT or interpreter)

You can also do this today as well.

> 3. can compile/interpret C/C++ sources _BASED_ on type info in
> precompiled bc
 
OK, I didn't quite understand what you meant at first, but it makes
sense with the rest of your message.  See the end of my response.

> Motivation:
[skip java-related stuff]
> Given that llvm bytecode might become a viable distribution format
> _ideally_ i would like to see a llvm object file format to carry
> similar kind of info for another pass of gcc/g++:
> 
> so with:
> A.[h, cxx] => A.bc
> B.[h, cxx] => B.bc
> C.[h, cxx] => C.bc
> [ABC].bc => ABC.bc
> 
> we can perform:
> llvm-g++ X.cxx -I ABC.bc
> 
> without having to access the header files [ABC].h.
> 
> But since llvm's type system is meant to be lang indep the best we can
> do is to make debugging info descriptive enough for future
> compilations, is this correct?

That sounds about right.  Another issue is that currently, aggressive
optimizations change the code substantially and if there were increased
debug information (which would be nice), they would have to be checked
and/or modified to be more conservative and respect the memory layout of
structures, etc.
 
> It would be nice to make bc files optionally carry type info useful
> for another compile pass (today bc files are only useful for linking).

I recon that would be a requirement to a fully-functional llvm-db
(debugger) so yes, it would be nice.  Patches are accepted. :)

-- 
Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu