similar to: [LLVMdev] recompilation

On Thu, 5 May 2005, Misha Brukman wrote: > On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: >> On May 5, Misha Brukman wrote: >>> To the best of my knowledge, this has not been done and no one has >>> announced their intent to work on it, so if you are interested, >>> you'd be more than welcome to do so. >> >> My C++ knowledge

On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: > On May 5, Misha Brukman wrote: > > To the best of my knowledge, this has not been done and no one has > > announced their intent to work on it, so if you are interested, > > you'd be more than welcome to do so. > > My C++ knowledge is completely non-existant, but so far I've had a >

LLVM list, I bumped into Alex Friedman in the hall today and by coincidence he mentioned that they were switching to LLVM for their PLT Scheme JIT project. I had evaluated LLVM a few weeks ago for my own purposes, but decided that it was too C/C++ centered and that critical features such as tail call optimization and other stack manipulation features were likely stagnant. So naturally I asked

On May 5, Misha Brukman wrote: > Maybe we can use you for a testimonial... :) Certainly. > > Tail Call Elimination: > > > > I've read over the "Random llvm notes", and see that you guys have > > though about this already. > > > > However, the note dates from last year, so I am wondering if there is > > an implementation in the works.

Hi Assuming I had an application stub based on (say) lli, and I'd like to allow a hypothetical IDE to recompile and relink a function: Is that supported in any way currently? Assuming actually patching all call sites to point to the newly generated function is possible, I guess what I need is to be able to either track or find all of the call sites. The trickiest bit seems to be if the

On Fri, Dec 31, 2004 at 02:30:00PM +0100, Francisco Puentes wrote: > Now I have other problem: I have a Module and I need generate a > iostream (memory) with native x86 code (maybe elf/coff) to be executed > later (into the guest process space, without fork!!). I studied llc > and lli, but they don't help me much. Any idea? Are there any guy > working in some like that? In

> >>> Would be great if we append into the documentation several "patters" > >>> to show how perform with LLVM. It would accelerate the learn curve for > >>> beginners like me, avoiding basic errors and mistakes. If I reach a > >>> good level with LLVM I can make these. > >> > >> I'm not sure if I understand what you

On Wed, 2004-08-04 at 07:38, Misha Brukman wrote: > On Wed, Aug 04, 2004 at 01:17:24AM -0500, Chris Lattner wrote: > > On Tue, 3 Aug 2004, Reid Spencer wrote: > > > I'm not thrilled with llvm-gen because it has overtones of "code > > > generation" (which actually isn't far from the truth). But, it > > > conjures up the wrong kind of tool ..

I compiled a simple "hello world!" C program on FreeBSD, transfered the a.out.bc file to Windows, and executed it with an lli.exe that I built with Visual Studio. It worked!

Hi, I am working with llvm 1.3 on a sparcv9 machine. I have successfully built llvm and llvm-gcc frontend. I can run many tools including llvmgcc, llvm-dis, and llc. After using /opt/SUNWspro/bin/cc to assemble .s file into a program binary, I can run the binary correctly as well. I am interested in the JIT compiler (lli). When I directly run the LLVM bytecode using interpretation ("lli

hi, I'm really new to llvm. I've successfully bootstrapped llvm-14 on my system and am able to successfully compile c code to llvm. the problem is now that gccld is complaining that it can't find the libraries, like "c" or "crtend". [1] all is fine, if I just use intrinsified functions like printf and friends, but I want to use the clock_gettime function and

On Sat, Jan 08, 2005 at 06:16:47PM +0100, Francisco Puentes wrote: > I have points 0-4 working, but I am confused about point 5 and maybe 6. [snip and reorder] > (5) Generate native (x86) code from generated module The JIT currently is built to generate native code for a given module, a function-at-a-time. That means that first, main() is generated, and anything main() calls is not. As

Hi Chris, It did compile when I gave that option. But it gives me an error when I try to run the executable on an Intel machine. ----- 1513158 is not prime. Exception handler needed, but not enabled. Recompile program with -enable-correct-eh-support. lli[0x8429bb4] lli[0x8429dc0] /lib/libc.so.6[0x40128c18] /lib/libc.so.6(abort+0x161)[0x40129cb5] [0x403da922] ../../../i386: line 4: 27606

Hi again, and thanks (Reid) for your fast response: Yes, it works!!! Only changing the order of libraries in the Makefile. Nowaday I have my software with the capability of compile assembly, bytecode (from buffer and file) and link them with a set of libraries. It seems to work perfectly (I don't generate code yet). My real aim is to have a process (host) with execute several no-jit

Hello, I have observed that the LLVM build takes pretty long time to link executables (i.e. tools). Is that a normal behavior? Thanks, Rahul

Karl, I think you meant to cc the llvmdev list on this. Thank you for a more detailed explanation, it's much clearer to me now. I agree that making the execution of .bc files more transparent would make it more useable as a stand-alone binary format on Unix-like systems and adding programmable support to changing the #! line would prevent much of user error involved in modifying the run

I have made few attempts to compile some software packages with llvm. My approach is to define Make variables as follows : export AS=llvm-as export LD=llvm-ld export AR=llvm-ar export CXX=llvm-g++ and then run configure and make. This approach works with very small code bases only. For most of the projects, it bails out with errors. Some of them are very clear, like llvm does not support

On Tue, 3 Aug 2004, Reid Spencer wrote: > > For the name, again, I'd be happy with either llvmcd or llvmgen, witha > > preference for the latter. The more important thing is to makellvm > > code be the default output. > > I'm not thrilled with llvm-gen because it has overtones of "code > generation" (which actually isn't far from the truth). But,

On Wed, Aug 04, 2004 at 08:19:58AM -0700, Reid Spencer wrote: > How about something along the notion of "build or construct" as in we > have two primary tools in llvm: > > llvm-build - builds programs to be run llvm-build or llvm-driver are both kinda long but at least they make sense... As an aside, llava and llama are both taken, llvmize? llvminator? llvm-emerge a la

> Yes, this is no problem. You can do something like > this: > > $ llvmgcc X.c -c -o X.bc > $ llc X.bc -o X.s > $ gcc Y.c -o Y.o -c > $ gcc X.s Y.o -o program > $ ./program Ok, fine, and what about the interpreter? It takes 100% llvm, doesn't it? Or is there some kind of import facility (perhaps as an specially interpreted call or as an extension to llvm which makes