[LLVMdev] Packages

Chris Lattner sabre at nondot.org
Sun Nov 16 13:03:01 PST 2003


> > Is this what you mean?  Is there any reason to keep the .bc files distinct
> > like a ".a" file, or is it ok for your purposes to link them together into
> > a single unit, like a ".so" file?
>
> Well, the answer depends on whether the individual modules are
> separately loadable or not. Suppose the resulting bytecode file gets JIT
> loaded into a running program. Is it all or nothing? What if the calling
> program new it needed a specific module from the larger optimized
> "package"? Can the original modules, now combined into the one .bc file,
> get loaded individually?

No, it's all or nothing.  Once linked, they cannot be seperated (easily).
However, especially when using the JIT, there is little overhead for
running a gigantic program that only has 1% of the functions in it ever
executed...

> For example, using Java, suppose I wanted to use java.util.zip.CRC32 to
> compute a checksum in a program. That class (module) is delivered to me
> as a java.util.zip "package". That is, it is the result of running
> llvm-link to produce a single bytecode file that includes all the
> classes with java.util.zip prefix. But (for some mysterious reason) the
> java.util.zip/CRC32 class was not compiled/linked/optimized into my
> program; its just referenced from it.  At runtime, the JIT needs to
> locate this module and compile/link it into my program. Now, if the
> CRC32 class (module) is part of a java.util.zip package (i.e. the output
> of llvm-link), what happens? Is the entire package loaded providing more
> than my program needs? Is the runtime linker smart enough to locate the
> CRC32 module in the optimized package output? Is it smart enough to load
> only the one module needed? Does the notion of module inside a module
> even exist?

There are multiple different ways to approach these questions depending on
what we want to do and what the priorities are.  There are several good
solutions, but for now, everything needs to be statically linked.  I
expect this to change over the next month or so.

> P.S. Bug 114 (-Wold-style-cast) has a patch ready.

I realize that.  I will get to it this afternoon, I'm still catching up
from PLDI.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/




More information about the llvm-dev mailing list