similar to: [LLVMdev] PATCH: ObjectFiles.html

One of the things that I don't understand well about LLVM is what code is in what object files or library archives. It would be very useful if there was a map of the dependencies between the files (e.g. if you link X.o you need Y.a and Z.o). Trying to figure out the link lines by trial and error is a bit frustrating. To assist myself with understanding this, I've started to write a

On Fri, 2004-02-27 at 07:20, Chris Lattner wrote: > > 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

On Fri, 27 Feb 2004, Reid Spencer wrote: > This works as long as the libraries are fine-grained _enough_. They > probably are so I'm not going to make an issue out of this because there > are bigger fish to fry. If not, they can always be split up later. :) > > Well, in the long term we want to switch everything over to docbook, at > > which point it should just be a

On Thu, 26 Feb 2004, Reid Spencer wrote: > One of the things that I don't understand well about LLVM is what code > is in what object files or library archives. It would be very useful if > there was a map of the dependencies between the files (e.g. if you link > X.o you need Y.a and Z.o). Trying to figure out the link lines by trial > and error is a bit frustrating. No

> 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

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

The default prefix is /usr/local but I would recommend that when you configure LLVm you do so with: configure --prefix=/me/llvm/install/dir ... so that installation occurs in a place you have write access. If you feel strongly about restoring the install-bytecode target, feel free to file a bug. Reid. On Thu, 2004-11-11 at 09:12, Jeff Cohen wrote: > Wow... it is nearly twice as fast. But

The entire makefile system was rewritten a couple of weeks ago. This is a good thing, your compiles now go twice as fast. Resistance is futile, just adapt :) The install target installed the bytecode libs into CFEINSTALL as before and also installs the native libraries to your prefix/lib directory. This is intentional. Reid On Wed, 2004-11-10 at 23:32, Jeff Cohen wrote: > But there already

I just found "entry". Its the name I gave a basic block at the start of the function (name was hard coded in the compiler, not the source). The issue here is probably that the block doesn't have a terminating instruction. However, that fact used to be caught well by the validator. Furthermore, the output from the byte code reader is a little confusing given the source of the

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

And, one more weird thing in this function. The FILESize static variable is never initialized so its likely initial value is 0 due to zero fill on many MMUs. The value is never written and used as a divisor. Why hasn't this function caused an arithmetic violation? Because the IOBBase point, also a static variable is initialized to zero and never modified and used in a conditional that thwarts

I forgot that lli was "special". It uses the "JIT" keywoard which means "figure out the right libraries to use for a JIT compiler and runtime". So, just add this, to tools/lli/Makefile: USEDLIBS := LLVMBCWriter That worked for me. Reid. On Thu, 2005-02-24 at 16:58, Patrick Meredith wrote: > Where do I add that line? Just putting it in the vanilla Makefile in

I mis-stated what I think should be deleted. The block of code from "GlobalVariable *IOB = 0;" to the end of the loop should be delted because the only effect the loop has is on the IOB variable and that variable is never used after the loop. Reid. On Tue, 2004-05-11 at 18:14, Reid Spencer wrote: > Hi, > > I'm working on bug 122, consolidating the interface to the

On Mon, 2005-07-25 at 21:48 -0700, Michael McCracken wrote: > On 7/25/05, Reid Spencer <reid at x10sys.com> wrote: > > Why not just create your pass as a shared object and: > > > > opt -load mypass.so -mypass | llc > > My pass is an implementation of an analysis group that I wanted to > make available to machine passes as well as optimization passes. So I >

Jeff, I tried the Benchmarks/Olden/power, Benchmarks/OptimizerEval, and Benchmarks/Ptrdist/ks tests. They all worked with your patches. I suggest you update your tree :) The changes also survived all the Feature and Regression tests on Linux. So, your changes are committed. Thanks for the patches! Reid. On Sun, 2004-08-29 at 16:01, Jeff Cohen wrote: > Fair enough... The following tests

On Sun, 2004-08-29 at 16:01, Jeff Cohen wrote: > Fair enough... The following tests under MultiSource fail: > > Benchmarks/Olden/power > Benchmarks/OptimizerEval > Benchmarks/Ptrdist/ks > Benchmarks/MallocBench/perl > Applications/sgefa > > However, they also fail in the exact same way without my change. > OptimizerEval appears to be non-deterministic; it produces

I'll wait for the research. We should try, as much as possible, to make it work with just what the compiler provides and without third party packages. Thanks, reid. On Fri, 2004-09-24 at 07:46, Jeff Cohen wrote: > I added the include of cstudio and it fails with plain VC7.1; the file > does not exist. > > Add it for now. If it is impossible to build with VC7.1 and without

Two suggestions: 1. m4 might be located by your PATH variable. 2. Talk to Morten Ofstad about how he got it to work. Reid. On Wed, 2004-11-03 at 19:34, Jeff Cohen wrote: > I have problems getting the GNU tools to execute properly. I installed > bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the > README. The installers for these packages did not want to put them

This kind of thing is one of the many reasons we broke llvm-test out to a separate project. It has multiple purposes. Its a correctness test on LLVM, its what we base our compiler benchmarks on, and its also where a lot of the research gets done. You've been bitten by the latt(n)er. :) At some point I'd like to see us make some distinctions so that there is a correctness test suite whose

Yeah, that's fine. I'll change it soon. Reid. On Thu, 2005-04-21 at 18:32 +0200, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > On Thu, 2005-04-21 at 17:56 +0200, Markus F.X.J. Oberhumer wrote: > > > >>Reid Spencer wrote: > >>> If a specific value for these is > >>> needed on a given platform, then we need to implement