similar to: [LLVMdev] tabs

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

See attached build (gmake -k) log. -- gaeke at uiuc.edu -------------- next part -------------- gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib' gmake[2]: Entering

Hello hackers, I seem to be having some trouble compiling the top of the llvm CVS tree... Is someone working on something involving IPModRef.cpp and the data structure graph? I have attached a make -k log. -Brian -- gaeke at uiuc.edu -------------- next part -------------- gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Nothing to be done for

Hello, Everyone. Now I have some spare time and I've decided to build LLVM on Mingw. I've grab the latest 1.7 release (not CVS snapshot). Here are some issues fixed during the build. Now I'm preparing gcc build. So, I think, there will some other "parts" 1. Prerequisites 1.1 GCC 3.4.5 from mingw.org site. $ gcc --version gcc.exe (GCC) 3.4.5 (mingw special) Copyright (C)

Some wheird problem, Target/X86 builds okay now. But there seems to be another problem with the Cygwin build :- make[4]: Entering directory `/usr/build/llvm/lib/Target/SparcV9/ModuloScheduling' llvm[4]: Compiling ModuloSchedulingSuperBlock.cpp for Debug build /usr/src/llvm/lib/Target/SparcV9/ModuloScheduling/ModuloSchedulingSuperBlock.cpp : In member function `virtual bool

Hi! I can't build LLVM using GCC 4.1 (GCC CVS mainline) after http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050328/025003.html Build terminated with error: /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/SparcV9/ModuloScheduling/DependenceAnalyzer.cpp:25: error: explicit qualification in declaration of `llvm::FunctionPass* llvm::createDependenceAnalyzer()' at line:

> LLVM already includes this: the -indvars pass. It turns things like this: > > int *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. You can check out

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

It seems that this happened before but I do not know the details: http://llvm.cs.uiuc.edu/testresults/SparcV9/2004-12-07.html Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > llvm[2]: Compiling zalloc.c for Release build > > /homes/myuser/LLVM/llvmobj/../llvmsrc/utils/Burg/zalloc.c:9: error: conflictin > > g types for

A question about how the memory of object in LLVM are managed. I dived in some source files but still don't have any idea how the memory of MachineInstr object are managed. It doesn't look like reference counting. I'm writing an instruction scheudling code, the new order of MachineInstr* in a MachineBasicBlock is stored in a "schedule". All MachineInstr* in

I commented this line and it is compiling now: extern void *malloc ARGS((unsigned)); I hope that will not cause a different kind of problem. What it is zalloc used for? Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > > It seems that this happened before but I do not know the details: > >

The problem with building the frontend on Windows is that gcc cannot be bootstrapped using Window's native compiler -- i.e. VC++ -- unlike every other platform. It can be built on Windows using gcc, of course, but even then only if the entire GNU environment is present. The real problem is that the bootstrapped frontend binaries built using gcc may not properly link with LLVM binaries built

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Hi, I'm able to build the llvm tools on the MinGW platform: burg, fpcmp, tblgen, llvm-as, llvm-dis, opt, gccas, llc, llvm-link, lli, gccld, llvm-stub, analyze and extract. I wonder if these tools are sufficient to start build the cfrontend? Henrik. _________________________________________________________________ Undg� pop-ups med MSN Toolbar - http://toolbar.msn.dk hent den gratis!

On Tue, 2 Nov 2004, Jeff Cohen wrote: > The problem with building the frontend on Windows is that gcc cannot be > bootstrapped using Window's native compiler -- i.e. VC++ -- unlike every > other platform. It can be built on Windows using gcc, of course, but > even then only if the entire GNU environment is present. Yeah, annoying. Unfortunately we're not up to fixing GCC :)

On Mon, 2 Oct 2006, Roman Levenstein wrote: >>> Wouldn't it be possible and even more clean to have just one >>> description like (I use a pseudo-description here): >>> >>> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, >>> (i8mem|i16mem|i32mem):$src), >>> "mov{b} {$src, $dst|$dst, $src}", []>,

Yes, sorry for not mentioning it. I added that header also Although I suppose that if I am not using Sparc there will be no problem (it's an Itanium 2 machine) Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > > I commented this line and it is compiling now: > > > > extern void *malloc ARGS((unsigned)); > >

It seems awfully tricky to get llvm working on a windows machine. I just want to use the tools, since I want to write my own front end. Here's where I get stuck llvm[2]: Linking Debug executable burg /usr/lib/gcc/i686-pc-cygwin/3.4.1/../../../libstdc++.a: could not read symbols: Archive has no index; run ranlib to add one collect2: ld returned 1 exit status make[2]: ***