similar to: [LLVMdev] Why the same code is much slower in JIT compared to separate executable?

Solved it. Looking at the source of bison, I found an undocumented environment variable M4 that points to the m4 binary. Setting it to the absolute path did the job. When not present, it ought to find it in the path as it uses execvp. At least on Unix. I have no idea what it does on Windows as I could not get the source used to build the Windows version (the installer claimed it installed the

> llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function, > etc. > > If kept simple, standardized, and generic, I think it would be very useful > to people (even if incomplete). This would allow others to build on it, > and we could 'ship' it as a standard llvm library. It looks like my interface will look vaguely like this. Functions like

On Thu, 12 May 2005, Alexander Friedman wrote: >> llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function, >> etc. >> >> If kept simple, standardized, and generic, I think it would be very useful >> to people (even if incomplete). This would allow others to build on it, >> and we could 'ship' it as a standard llvm library. > > It

Here's my translation of the Fibonacci example into OCaml: open Printf open Llvm let build_fib m = let fibf = define_function "fib" (function_type i32_type [| i32_type |]) m in let bb = builder_at_end (entry_block fibf) in let one = const_int i32_type 1 and two = const_int i32_type 2 in let argx = param fibf 0 in set_value_name "AnArg" argx; let

On Sep 23, 2004, at 4:08 PM, Jeff Cohen wrote: > MSVC++ is picky about this. It considers classes and structs to be > different types so you have to be consistent. If you forward declared > a > struct as a class within the same compilation unit, it would complain > about that too. It's not just linking. You are right... BTW, I've just fixed that problem in my checkout

I have just committed a change to Value.h that changes the Value class from using a "struct" declaration to a "class" declaration. I'm not sure why VC7.1 would generate different symbols for class vs. struct. I'm pretty certain that's a violation of the ABI. In any event, we should be consistent. The Value class is declared "class Value" in numerous places

Valery, That's pretty cute actually. Do you want this "brilliant" :) example in the cvs repository? I'd be happy to put it in. Reid. Valery A.Khamenya wrote: > Hi LLVMers, > > the example attached I have used to prove that JIT and some visible > optimizations are really invoked. > > Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 >

Hi all, I am currently porting my project to branches/release_26 and I noticed the JIT doesn't seem to work anymore when used in 64-bit. Every the very simple HowToUseJIT example crashes at runtime. $ gdb --arg ./Release/examples/HowToUseJIT GNU gdb 6.3.50-20050815 (Apple version gdb-1339) (Sat May 23 05:39:07 UTC 2009) Copyright 2004 Free Software Foundation, Inc. GDB is free software,

On second thought, the makefiles don't (easily) allow this do they? You can only build one program per directory. Were you suggesting that you wanted me to move the entire directories under a "small examples" directory? Reid. Chris Lattner wrote: > On Tue, 17 Aug 2004, Reid Spencer wrote: > > >>That's pretty cute actually. Do you want this

On Wed, 12 Apr 2006 23:02:12 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > > > I'd like to directly create executable code that i can > > stick in memory somewhere and jump into (call). > > Take a look at the llvm/examples directory. There are several small > programs that create LLVM IR on the fly and JIT compile it. I'm trying to take

On Tue, 17 Aug 2004, Reid Spencer wrote: > On second thought, the makefiles don't (easily) allow this do they? You can > only build one program per directory. Were you suggesting that you wanted me to > move the entire directories under a "small examples" directory? You're right. The simples way to do this would be to have: projects/ SmallExamples/

On Tue, 17 Aug 2004, Reid Spencer wrote: > That's pretty cute actually. Do you want this "brilliant" :) example in the cvs > repository? I'd be happy to put it in. Here's an idea: how about we take the ModuleMaker, Valery's previous example, and this one and put them all in one "small examples" project? -Chris > Valery A.Khamenya wrote: > >

Like I said, it is in my path. That's not enough. I'd be happy if Morten chimed in with any suggestions as to how he got it to work. On Thu, 04 Nov 2004 18:45:18 -0800 Reid Spencer <reid at x10sys.com> wrote: > 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

On Thu, 13 Apr 2006 18:07:42 +0200 Oscar Fuentes <oscarfv at telefonica.net> wrote: > > Simon Burton <simon at arrowtheory.com> writes: > > > I'm trying to take assembly and create machine code I can execute. > > How close am I ? > > Your test case is not complete. Besides, which version of llvm are you > using? What are the commands for compiling

On Thu, 5 May 2005, Alexander Friedman wrote: >>> Does there happen to be a C interface to the jit ? Our scheme impl >>> has a good FFI, but it doesn't do C++. If not, this is no big deal, >>> and i'll just write something myself. >> >> No, but such bindings would be *very useful*. And since there might be >> other people who need them this

On 04/29/2010 11:44 AM, Yuri wrote: > > I run the same simple Fibonacci computing code in JIT and as a native > executable. I see that with argument 45 JIT runs for 11.3sec and > executable runs for 7.5sec. > Why there is such difference? How long does it take for llc to compile it? Remember that the JIT includes code generation time. Best regards, --Edwin

> So as it stands, one should think of out JIT as something akin to the > early Java JITs: one function at a time and only one compile per > function. This is extremely primative by modern JIT standards, where a > JIT will do profiling, find hot functions and reoptimize them, > reoptimize functions when more information about the call tree is > available, have several levels of

Yuri <yuri at tsoft.com> writes: >> With >> >> time lli -O3 fib.bc 45 >> >> you are measuring the time lli takes optimizing the LLVM code, >> generating the native code and, finally, executing it. If you add to >> this the debug asserts, it is not surprising that lli ends being quite a >> bit slower than directly executing the native code >

When I compile my C fibonacci example fib.c with 'clang -O3 -c -emit-llvm -o fib-clang.bc fib.c&& llvm-dis fib-clang.bc' I get fib-clang.ll that has some degree of inlining in it. But when I get an equivalent to fib.c file fib.ll and run it through opt with the command 'llvm-as fib.ll&& opt -O3 fib.bc -o fib-opt.bc&& llvm-dis fib-opt.bc' resulting

Török Edwin wrote: > Are you using 2.6 or 2.7, 32-bit or 64-bit? > I use 2.7 on i386. lli has debug asserts enabled, but I guess this shouldn't matter for JIT code speed. jit: 11.32 real exe: 7.64 user Both have -O3 option. Speed should be the same. Yuri