On Fri, 27 Feb 2004, Chris Lattner wrote:> > Could someone please add this file to the LLVM docs directory so I can > > submit patches against it?BTW, here's some hints for it: libtransforms.a -> contains only the level raise pass libtarget.a -> contains code generator support for describing target architectures libanalysis.a -> intraprocedural analyses libipa.a -> interprocedural analyses libinstrument.a -> instrumentation (e.g. profiling) transformations libtransformutils.a -> common code shared by various xforms libregalloc.a -> sparc register allocator sched.o -> sparc instruction scheduler select.o -> sparc instruction selector support libevar.o -> live variable analysis for the sparc selectiondag.o -> start of aggressive instruction selector for DAGs profpaths.o -> path profiling instrumentation Basically, libraries are built in two forms: .a files and .o files. .o files are built/used when client programs want to link in _everything_ in a library. .a files are used when a client program wants to use some of the stuff in a library, based on what symbols are referenced. The difference is important for things like 'opt' which wants to link in _ALL_ optimizations no matter what, and 'gccas' which only wants to link optimizations in that are referenced by the gccas tool explictly. For libraries that .a files don't make sense, we don't provide them. It's impossible to link in half an x86 backend for example. :) Overall, this looks really useful, especially when the dependency information is built. Perhaps this should eventually be integrated into the programmers manual though? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Thu, 2004-02-26 at 22:41, Chris Lattner wrote:> On Fri, 27 Feb 2004, Chris Lattner wrote: > > > Could someone please add this file to the LLVM docs directory so I can > > > submit patches against it? > > BTW, here's some hints for it:Thanks Chris, I'll add them.> Basically, libraries are built in two forms: .a files and .o files. .o > files are built/used when client programs want to link in _everything_ in > a library. .a files are used when a client program wants to use some of > the stuff in a library, based on what symbols are referenced. > > The difference is important for things like 'opt' which wants to link in > _ALL_ optimizations no matter what, and 'gccas' which only wants to link > optimizations in that are referenced by the gccas tool explictly. > > For libraries that .a files don't make sense, we don't provide them. It's > impossible to link in half an x86 backend for example. :)While I understand the motivations you describe above, something about this bothers me. As a tool provider the LLVM developers are trying to provide small/fast/quick linking tools. The above approach helps with some of that. However, I'm an LLVM user and a big part of using LLVM is linking my code with LLVM code. When the LLVM developers opt to make a .o "library", they're essentially forcing users to take all or nothing. As you mentioned in the case of x86 backend, this may make a lot of sense. On the other hand, it presumes the developers of LLVM know how the users want to use LLVM! Say there's a little utility function in the x86 backend that I want to use but I'm not generating any x86 code?> > > Overall, this looks really useful, especially when the dependency > information is built. Perhaps this should eventually be integrated into > the programmers manual though?Perhaps, but with hypertext, what does "integrated" really mean? :)> > -Chris-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040227/d6a11be3/attachment.sig>
> While I understand the motivations you describe above, something about > this bothers me. As a tool provider the LLVM developers are trying to > provide small/fast/quick linking tools. The above approach helps with > some of that. However, I'm an LLVM user and a big part of using LLVM is > linking my code with LLVM code. When the LLVM developers opt to make a > .o "library", they're essentially forcing users to take all or nothing.Exactly.> As you mentioned in the case of x86 backend, this may make a lot of > sense. On the other hand, it presumes the developers of LLVM know how > the users want to use LLVM! Say there's a little utility function in > the x86 backend that I want to use but I'm not generating any x86 code?If you're not generating X86 code, don't use the X86 library. :) The idea is that LLVM is broken up into libraries that are already probably already too fine-grained. If you don't need something, just don't link to it...> > Overall, this looks really useful, especially when the dependency > > information is built. Perhaps this should eventually be integrated into > > the programmers manual though? > > Perhaps, but with hypertext, what does "integrated" really mean? :)Well, in the long term we want to switch everything over to docbook, at which point it should just be a matter of doing the equiv of "#include ObjectFiles.html", and we suddenly have a new section in the book... -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/