similar to: [LLVMdev] Saving/restoring executable code from the the JIT?

It's not clear how valuable the feature is if users start to do things like inlining pointers to heap allocated objects with guards as optimizations. I could imagine an IR class representing a pointer to an object on the heap that gets serialized to bitcode as some kind of relocatable symbol, and then re-resolved at runtime. If the corresponding symbol doesn't exist at runtime, the

2009/9/12 Reid Kleckner <rnk at mit.edu>: > It's not clear how valuable the feature is if users start to do things > like inlining pointers to heap allocated objects with guards as > optimizations. or what about register variables, or objects half as registers half in memory, or optimizations that exists on one machine (presence of FPU, MMU, etc) and not on others, byte sex,

Renato Golin <rengolin at systemcall.org> writes: > or what about register variables, or objects half as registers half in > memory, or optimizations that exists on one machine (presence of FPU, > MMU, etc) and not on others, byte sex, word size and many other > problems... All of this is the job of serialization engine. [snip] My goal is to avoid waiting several minutes on

2009/7/4 Albert Graef <Dr.Graef at t-online.de>: > This is all I ever needed to interface to C functions using LLVM. It's > really easy. Of course you still need a prototype of the external > function (function definition without body) in your IR, but that's it. Hi Albert, I'm having a similar problem and I found I can't declare the function and use it, most likely

> Inline the init function: store 11 at the address of the "value" variable, > call printf with the string from r5. This is a bug, should have stored at an > offset of four (str r1, [r4,4]). Exactly! The IR is correct, the bug seems to be lower down. I'm no expert in the ARM back-end, though. But your report is detailed enough to help whoever is. ;) cheers, --renato

John McCall wrote: > On Jul 2, 2009, at 1:05 AM, Carter Cheng wrote: >> I am having some difficulties getting the LLVM JIT to resolve extern >> "C" functions which I have defined in source file and invoking them >> via EE::runFunction() after generating a Function prototype for it. >> Is this possible or do I need to generate a .so for my functions are

I think you might have to provide an empty list if your function doesn't take parameters. Maybe using an irbuilder would help? -bw On Aug 22, 2009, at 2:13 PM, Renato Golin <rengolin at systemcall.org> wrote: > 2009/7/4 Albert Graef <Dr.Graef at t-online.de>: >> This is all I ever needed to interface to C functions using LLVM. >> It's >> really

2009/9/15 Patrick Simmons <simmon12 at illinois.edu>: > cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" > -DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD="X86;PowerPC;CBackend" > /home/renato/llvm-sources Thanks Patrick, I'll give it a try. At least now I know that it can be done. My previous attempts all ended up in memory

On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote: > > >> In this case, the assertion that LLVM is slow is correct: it's >> definitely slower than a non-optimizing compiler. > > I'm *very* surprised by this and will test it myself... Compared to a compiler in the same category as PCC, whose pinnacle of optimization is doing register allocation? I'm not

> My goal is to avoid waiting several minutes on application startup > until > optimization and native codegen ends. No suspending/restarting, just > compiling, saving native generated code, and loading on future sessions, > more akin a conventional compiler. > I'm interested in something like that. I have a case (which seems similar to one experienced by Nick Capens) where

Thanks for answer, Renato. But I still thing that there is some issue with ARM codegen. When I tried running your code you modified I got exactly same LLVM IR result (verified it by comparing output from llvm-dis) - and program on runtime still produces wrong result. With some help from another developer we managed to reduce issue to following C code that is simpler: #include <stdio.h>

Thanks for confirming this. Is there anybody with experience with ARM JIT codegen who can take a look into this? Or can somebody direct where to look how JIT on ARM processes getelementptr instruction? -- Martins Mozeiko On Feb 17, 2010, at 19:14 , Renato Golin wrote: >> Inline the init function: store 11 at the address of the "value" variable, >> call printf with the

Hello, llvm developers! I am running LLVM with JIT on ARM. For simple programs it runs ok, but for lager code I have stumbled upon some issues. See following C++ code to which I have reduced the problem: #include <stdio.h> struct Global { typedef unsigned char ArrayType[4]; ArrayType value; Global(const ArrayType& arg) { for (int i = 0; i < 4; i++) this->value[i] =

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: >> If I activate the Inliner pass: >> >>    Builder.Inliner = createFunctionInliningPass(Threshold); >> >> this is the result: >> >> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >> >> It happens on almost all my test

2009/10/18 Oleg Knut <oleg77 at gmail.com>: > Maybe some of you can guide me on how to do following operations: >  1) prevent system calls >  2) memory allocation management (set some limits that can't be used > by JIT) >  3) CPU power limiting Hi Oleg, This is totally system dependent, it'd be *very* hard to do it multi-platform. On Unix, a good part of it is

2009/10/28 Chandler Carruth <chandlerc at google.com>: > Surviving new and different uses > *is* the purpose of a good interface. I don't have much to add to this interesting discussion, just like to remind people that changes in the default behaviour are only acceptable (IMHO) when everybody (but a few legacy code) is NOT using (or should not use) the current default behaviour.

Chris Lattner writes: > On Nov 21, 2009, at 1:00 PM, Arnt Gulbrandsen wrote: > >> Chris Lattner writes: >>> I'm still really interested in making Clang (and thus LLVM) faster >>> at -O0 (while still preserving debuggability of course). >> >> Why? > > I want the compiler to build things quickly in all modes, but -O0 in > particular is

On 15 February 2010 14:49, Martins Mozeiko <49640f8a at gmail.com> wrote: > #include <stdio.h> > struct Global { >  typedef unsigned char ArrayType[4]; >  ArrayType value; >  Global(const ArrayType& arg) { >    for (int i = 0; i < 4; i++) this->value[i] = arg[i]; >  } > }; > static const unsigned char arr[] = { 1, 2, 3, 4 }; > static const Global

On Nov 21, 2009, at 1:00 PM, Arnt Gulbrandsen wrote: > Chris Lattner writes: >> I'm still really interested in making Clang (and thus LLVM) faster at -O0 (while still preserving debuggability of course). > > Why? I want the compiler to build things quickly in all modes, but -O0 in particular is important for a fast compile/debug/edit cycle. Are you asking why fast compilers

Hi all, Is anyone using any flavour of Unix to develop LLVM? I suppose the Apple guys are using Mac, right? ;) I've seen some docs on the website to set-up Visual Studio but I haven't seen anything related to cross-platform IDEs (such as Eclipse) and how to attach the tests to them. So far I'm not doing any modifications to the LLVM and my project is still too small to become a