search for: classllvm_1_1executionengine

...JIT is not a secure VM like Java. Programs running under the JIT are > free to make any memory operation or function call that the enclosing > program could, even _exit(). You can try to restrict function calls by > removing the name resolution: > > > > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460 > > and/or installing your own (see InstallLazyFunctionCreator), but ultimately > they're the same process/task from the point of view of the operating system > and there's no "llvm security model" or anything like that. > >...

Hi! I'm trying to develop JIT compiler using LLVM as its backend. I know LLVM itself supports JIT-compiling, but I need to generate IR first. I don't want to generate IR before function is actually needed. How can I achieve this? If it matters, I have prototypes for all functions I'm going to use. Best regards, Milovanov Victor.

...ompiling, but I need to generate IR first. > I don't want to generate IR before function is actually needed. How > can I achieve this? > If it matters, I have prototypes for all functions I'm going to use. See ExecutionEngine::InstallLazyFunctionCreator(). http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#6a126d6cd1fa07a4331179597de0c46a Nick

Ok than, but how to insert a call to an undefined function? > See ExecutionEngine::InstallLazyFunctionCreator(). > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#6a126d6cd1fa07a4331179597de0c46a > > Nick >

http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html "Constant*" misspelled as "Constnat*" at: GenericValue ExecutionEngine::getConstantValue ( const Constant * C ) [protected] Sandro

...vm.org/docs/Passes.html Unlike Java, you're in the driver's seat. You can determine which optimizations are applied to your code, and when. > do you have something along lines of JVM's hotspot feature? You can recompile a function in the JIT at any time. http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#a18 However, LLVM does not yet have support frame rewriting; you cannot re- optimize and resume a function that is on the call stack. > How efficient is the optimized code vis-a-vis native code? It is native code! :) LLVM is also an excellent static compiler (see llvm-gcc, clang). —...

Hello, (im new to LLVM , so pl excuse if this is a naive q). Can someone provide info on what runtime optimizations are done in LLVM? do you have something along lines of JVM's hotspot feature? How efficient is the optimized code vis-a-vis native code? thanks -kamal ____________________________________________________________________________________ Never miss a thing.

...be circumvented? Fork? LLVM JIT is not a secure VM like Java. Programs running under the JIT are free to make any memory operation or function call that the enclosing program could, even _exit(). You can try to restrict function calls by removing the name resolution: http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460 and/or installing your own (see InstallLazyFunctionCreator), but ultimately they're the same process/task from the point of view of the operating system and there's no "llvm security model" or anything like that. If you're very determ...

Hi, I'm doing some tests concerning the embedding of LLVM and clan in my application. Now I stumbled across the following ... which disturbs me. If the jitted program crashes, like e.g. if it contains an assert(0==1) or calls an external function which cannot be resolved, the hosting app goes down as well. There seems no error catch. Can this anyhow be circumvented? -Frank

...k? > > LLVM JIT is not a secure VM like Java. Programs running under the JIT are free to make any memory operation or function call that the enclosing program could, even _exit(). You can try to restrict function calls by removing the name resolution: > > > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460 > > and/or installing your own (see InstallLazyFunctionCreator), but ultimately they're the same process/task from the point of view of the operating system and there's no "llvm security model" or anything like that. > > If you&...

...Java. Programs running under the JIT are >> free to make any memory operation or function call that the enclosing >> program could, even _exit(). You can try to restrict function calls by >> removing the name resolution: >> >> >> >> http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460 >> >> and/or installing your own (see InstallLazyFunctionCreator), but >> ultimately they're the same process/task from the point of view of the >> operating system and there's no "llvm security model" or anything like...

...uot; instead of "define": > http://llvm.org/docs/LangRef.html#functionstructure > > > If you're using the JIT, you'll need to do the above, but also may need to > register your functions using > ExecutionEngine::addGlobalMapping. > > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#a8 > > > Note that the C calling convention do not map directly to LLVM IR for many > cases, so it's best to stick to simple parameter types (pointers and ints, > for example) and also to verify that the LLVM FunctionTypes you use are > correct on each platform you suppor...

...bly, use the keyword "declare" instead of "define": http://llvm.org/docs/LangRef.html#functionstructure If you're using the JIT, you'll need to do the above, but also may need to register your functions using ExecutionEngine::addGlobalMapping. http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#a8 Note that the C calling convention do not map directly to LLVM IR for many cases, so it's best to stick to simple parameter types (pointers and ints, for example) and also to verify that the LLVM FunctionTypes you use are correct on each platform you support. Good luck! — Gordo...

...to the memory so that we > can run it from there without much magic (and then cache it > somewhere)? You can use the facilities of ExecutionEngine to run code in-memory without ever touching the filesystem. The LLVM tutorial has information on how to do this. http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html http://llvm.org/docs/tutorial/LangImpl4.html You'll probably want to provide your opcode handlers as an LLVM IR module. Your JIT can start up and “seed” the execution environment with the predefined handlers, then progressively incorporate more functions into the module as execution...

Hello, I got very interested in LLVM project, and I decided to start writing my own scripting language based on it. By studying the documentation, I could not find how to call external function, written in C. That is, I have a set of functions written in C/C++, I generate code, using LLVM C++ interface, how can I call(or register in machine in run-time) my external functions? Maybe I just missed

...http://llvm.org/docs/LangRef.html#functionstructure > > > > > > If you're using the JIT, you'll need to do the above, but also may > need to > > register your functions using > > ExecutionEngine::addGlobalMapping. > > > > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#a8 > > > > > > Note that the C calling convention do not map directly to LLVM IR for > many > > cases, so it's best to stick to simple parameter types (pointers and > ints, > > for example) and also to verify that the LLVM FunctionTypes you use > are...

...t;: >> http://llvm.org/docs/LangRef.html#functionstructure >> >> >> If you're using the JIT, you'll need to do the above, but also may need to >> register your functions using >> ExecutionEngine::addGlobalMapping. >> >> http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#a8 >> >> >> Note that the C calling convention do not map directly to LLVM IR for many >> cases, so it's best to stick to simple parameter types (pointers and ints, >> for example) and also to verify that the LLVM FunctionTypes you use are >> correct on...

...'t actually tried this, but it seems to be the only way to use this API, so I presume someone else has. The only potential problem I can forsee is if the JIT isn't actually re-entrant. Nick > >> See ExecutionEngine::InstallLazyFunctionCreator(). >> http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#6a126d6cd1fa07a4331179597de0c46a >> >> Nick >> >

...u have something along lines of JVM's hotspot > feature? > > You can recompile a function in the JIT at any time. > I am interested in optimizing code that was compiled using a C/C++ compiler. So, I will have binaries but probably not the source code. > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#a18 > > However, LLVM does not yet have support frame rewriting; > you cannot re- > optimize and resume a function that is on the call stack. > > > How efficient is the optimized code vis-a-vis native > code? > > It is native code! :) LLVM is also an excellent...

Hi, That seems really simple... just changing the function pointer. But how to do it for the 'printd' function in the Kaleidoscope example? An example how to do this would be super-great. Any help will be much appreciated. Thanks! On Sat, Oct 9, 2010 at 3:55 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > 2010/10/9 António Saragga Seabra <antseabra at gmail.com>: