similar to: [LLVMdev] JIT'ing constant globals

On Mon, 12 Jun 2006, Simon Burton wrote: > It seems one can only put constant global statements > _before_ any functions are defined, not after. This is true in .ll files, but not necessary in LLVM modules. > I would like to produce eg. "hello world!" functions in a JIT. > So I was hoping to use global string constants. > Is there another way to do this kind of thing ?

On Mon, 12 Jun 2006 12:27:36 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > On Mon, 12 Jun 2006, Simon Burton wrote: > > It seems one can only put constant global statements > > _before_ any functions are defined, not after. > > This is true in .ll files, but not necessary in LLVM modules. Yes, I'm generating .ll files. I'm using a workaround:

Is it possible to get llvm to generate native machine code without using gcc and friends ? Do I use lli ? I'd like to directly create executable code that i can stick in memory somewhere and jump into (call). (I'm looking to use llvm in a BSD licensed project). Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

Hi, I'm building a little JIT that creates functions to do array manipulations, eg. sum all the elements of a double* array. I'm writing this in python, generating llvm assembly intructions and piping that through a call to ParseAssemblyString, ExecutionEngine, etc. It's working OK on integer values, but i'm getting nasty floating point exceptions when i try this on double*

Hi, Is there a way to find out how much memory some JIT'ed machine code uses ? Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

On Fri, 5 May 2006 01:19:08 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > > On Fri, 5 May 2006, Simon Burton wrote: > > This leads me to my next question: as I make more and more functions > > with the EE, it slows down. I am re-using the Module, ExistingModuleProvider, > > and ExecutionEngine, and pumping the parser like so: > > M =

On Sat, 15 Apr 2006 07:47:00 +0200 Oscar Fuentes <oscarfv at telefonica.net> wrote: > > BTW, Simon, is there a reason for writing LLVM assembler and not > generating LLVM code directly? You mean write C++ code that calls the LLVM library ? I have a mild C++ allergy that I don't wish to aggravate. > The later is simpler and relieves you > from some nasty burdens. Yes,

On Tue, 18 Apr 2006 23:27:39 -0700 Evan Cheng <evan.cheng at apple.com> wrote: > Hi Simon, > > The x86 backend does generate scalar SSE2 instructions. For your > example, it should emit something like: Oh, how did you get this ? [...] > > There is nothing here that should cause an exception. Are you using a > release or cvs? CVS. >From what I remember,

On Tue, 20 Jun 2006 22:38:24 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > > >> Is this really the number of bytes of machine code ? > > Yes. > > To be specific, this is the number of bytes of machine code JIT'd. Thus, > this only includes the stuff reachable from main, for example. To see > specifically what functions it is compiling and

On Fri, 14 Apr 2006 03:25:39 +0200 Oscar Fuentes <oscarfv at telefonica.net> wrote: ... > Simon, > > With a fresh CVS checkout, I've tried your test case on Windows/VC++ > and it works ok. Too bad that I have not access to a Linux machine > right now. I'll like to see what's wrong with your test case. > > What you get from running the test case under gdb

Hi Simon, The x86 backend does generate scalar SSE2 instructions. For your example, it should emit something like: .text .align 4 .globl _sum_d _sum_d: subl $12, %esp movl 20(%esp), %eax movl 16(%esp), %ecx cmpl $0, %eax jne LBB_sum_d_2 # cond_true.preheader LBB_sum_d_1: # entry.bb9_crit_edge pxor %xmm0,

Segfault in EE->getPointerToFunction. I think it's blown the stack, gdb reports a never ending backtrace (below). I generate llvm assembly and parse/verify OK. Attached is the assembly. It is the smallest example generated that causes the segfault. If this EE uses a recursive function (??), it seems an inherent limitation in how big llvm functions can be. Simon. gdb backtrace: #0

On Apr 12, 2006, at 10:23 PM, Simon Burton wrote: > > Is it possible to get llvm to generate native machine code > without using gcc and friends ? Do I use lli ? llc. llc --help lists all the options. it compiles llvm bytecode files. > > I'd like to directly create executable code that i can > stick in memory somewhere and jump into (call). > > (I'm looking

Hi Simon, You're probably right. LLVM's instruction selector is recursive so it can run out of stack space. Select_store used to have enormous stack frame (thanks to some gcc issues), we had to do all kinds of tricks to get it under control. I just took a look at it, it's around 0.7k. It used to be around 20k on x86 Mac OS X. It's also possible that it has gotten into a

>From CVS: llvm[3]: Compiling SJLJ-Exception.cpp for Debug build (bytecode) SJLJ-Exception.cpp:16:19: cstdlib: No such file or directory SJLJ-Exception.cpp:17:19: cassert: No such file or directory SJLJ-Exception.cpp: In function `void SJLJDestructor(llvm_exception*)': SJLJ-Exception.cpp:43: error: `free' undeclared (first use this function) SJLJ-Exception.cpp:43: error: (Each

Hi, I've read over the "LLVM Language Reference Manual" a few times, and writing some ll code, but i'm stuck at a very basic point. How to decrement a counter variable ? int %count(int %n) { EntryBlock: %cond = seteq int %n, 0 br bool %cond, label %Exit, label %Next Next: ; how to decrement n ? %new_n = sub int %n, 1 br label %EntryBlock Exit: ret int 0 } I guess I

Simon Burton <simon at arrowtheory.com> writes: > Hi, > > I've read over the "LLVM Language Reference Manual" > a few times, and writing some ll code, but i'm stuck at > a very basic point. How to decrement a counter variable ? > > int %count(int %n) { > EntryBlock: > %cond = seteq int %n, 0 > br bool %cond, label %Exit, label %Next >

On Fri, 5 May 2006, Simon Burton wrote: > This leads me to my next question: as I make more and more functions > with the EE, it slows down. I am re-using the Module, ExistingModuleProvider, > and ExecutionEngine, and pumping the parser like so: > M = ParseAssemblyString(AsmString, M); > ISTM that there should be a way of creating multiple modules/EEs but I ran > into trouble

On Tue, 20 Jun 2006, Chris Lattner wrote: > On Wed, 21 Jun 2006, Simon Burton wrote: >> This from the output: >> >> 24620 x86-emitter - Number of machine instructions emitted >> >> (i had to write a dummy main function to get this to work) >> >> Is this really the number of bytes of machine code ? > Yes. To be specific, this is the

On Fri, 5 May 2006 16:43:13 +1000 Simon Burton <simon at arrowtheory.com> wrote: > > It slows in the construction phase, so one of these calls: > M = ParseAssemblyString(AsmString, M); > verifyModule( *M ) > M->getNamedFunction(name); > EE->getPointerToFunction > > It feels like there is a linear name lookup going on somewhere. it's