similar to: [LLVMdev] JIT simple module and accessing the value fails

Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] JIT simple module and accessing the value fails"

2017 Jan 25
2
mcjit C interface problems
Hi, I'm attempting to use MCJIT with the C interface with llvm-3.9.0, and it doesn't seem to work. This code is derived from Paul Smith's example code: int main(int argc, char const* argv[]) { LLVMModuleRef mod = LLVMModuleCreateWithName("my_module"); LLVMTypeRef param_types[] = {LLVMInt32Type(), LLVMInt32Type()}; LLVMTypeRef ret_type =
2012 Apr 25
2
[LLVMdev] Crash in JIT
Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =
2012 Apr 25
0
[LLVMdev] Crash in JIT
Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best
2017 Jan 26
2
mcjit C interface problems
Thanks for the tip - getting closer: $ ./capi_test 5 6 args[0]: 5 args[1]: 6 result: 4294959200 Here's the code I changed: printf("args[0]: %d\n", (int)LLVMGenericValueToInt(args[0], 0)); printf("args[1]: %d\n", (int)LLVMGenericValueToInt(args[1], 0)); uint64_t (*func)(); func = (uint64_t (*)())LLVMGetFunctionAddress(engine, "sum");
2010 Aug 12
3
[LLVMdev] LLVM-C: Calling functions contained in other libraries
Hello, I have a question concerning llvm-c. I have set up a function that needs to invoke an external method, in a other library. It has the following signature: void* NSFullUserName(void); The void* can be replaced with a i8*, that far I was able to get, but when my call is invoked, the engine gives me the following message: LLVM ERROR: Tried to execute an unknown external function: i8* ()*
2010 Aug 12
0
[LLVMdev] LLVM-C: Calling functions contained in other libraries
On Aug 12, 2010, at 10:43 AM, F van der Meeren wrote: > Where am I going wrong here? > Did you link against the library that contains the function? -eric
2009 Nov 05
2
[LLVMdev] Strange error for libLLVMCore.a
mingw, llvm 2.6 (buid with llvm-gcc) Example source code: http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html I change LLVMCreateJITCompiler(&engine, provider, &error); to LLVMCreateJITCompiler(&engine, provider, 3, &error); $ llvm-gcc `llvm-config --cflags` -c fac.c $ g++ `llvm-config --libs --cflags --ldflags core analysis executionengine jit
2016 Aug 10
2
crash JIT with AVX intrinsics
Hi all, I have some old code using the JIT via the LLVM-3.0-C API. I want to upgrade to newer versions of LLVM. As a simple example I wrote a C program that creates the following function and calls it: ; ModuleID = 'round-avx.bc' target triple = "x86_64-pc-linux-gnu" define void @round(<8 x float>*) { _L1: %1 = load <8 x float>* %0 %2 = call <8 x
2016 Jul 11
2
More function signatures for LLVMRunFunction?
Hello, I am new to LLVM, and came across a snag when working through tutorials. With the MC JIT execution engine, LLVMRunFunction only works on "main()"-like functions -- other functions fail with the message "Full-featured argument passing not supported yet!". The workaround recommended by the tutorials is to create a main()-compatible wrapper function and to send in
2010 Oct 25
0
[LLVMdev] Ocaml bindings for execution engines
Hi All, Here is the code from bindings/ocam/executionengine/executionengine_ocaml.c. /* llvalue -> GenericValue.t array -> ExecutionEngine.t -> GenericValue.t */ CAMLprim value llvm_ee_run_function(LLVMValueRef F, value Args, LLVMExecutionEngineRef EE) { unsigned NumArgs; LLVMGenericValueRef Result, *GVArgs; unsigned I; NumArgs =
2008 Sep 12
1
[LLVMdev] [PATCH] Link in codegen components in llvm-c
This allows the use of shadow stack from the llvm-c API. I am not sure this is the place to insert the include, though. Index: include/llvm-c/ExecutionEngine.h =================================================================== --- include/llvm-c/ExecutionEngine.h (revision 56175) +++ include/llvm-c/ExecutionEngine.h (working copy) @@ -24,6 +24,7 @@ #ifdef __cplusplus extern "C" {
2008 Mar 04
1
[LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient.
I noticed that the ocaml compilation isn't using the .opt executables if they're available. We might gain a slight optimization in ocaml compile time by optionally using them with this patch. --- autoconf/configure.ac | 18 +++++ configure | 195 ++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 188 insertions(+), 25 deletions(-) -------------- next part
2008 Mar 04
1
[LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation.
--- bindings/ocaml/llvm/llvm.ml | 2 +- bindings/ocaml/llvm/llvm.mli | 2 +- bindings/ocaml/llvm/llvm_ocaml.c | 2 +- include/llvm-c/Core.h | 32 +++++++++++++++++++------------- 4 files changed, 22 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff Type:
2011 Oct 13
0
[LLVMdev] BasicBlock succ iterator
thank john, i have used dump() , and each blocks had pred except entery block, i get the following output: fun main entry entry: %retval = alloca i32 %0 = alloca i32 %i = alloca i32 %j = alloca i32 %a = alloca [2 x i32] %n = alloca i32 %t = alloca i32 %"alloca point" = bitcast i32 0 to i32 %1 = getelementptr inbounds [2 x i32]* %a, i32 0, i32 0 %2 = load i32*
2016 Jul 15
2
More function signatures for LLVMRunFunction?
Hi Lang, Thanks for the reply. Responses below. As far as I know nobody is actively working on MCJIT any more. I've been > working on the next generation of LLVM JIT APIs (ORC - see > include/llvm/ExecutionEngine/Orc) for a while now, but they don't have > functionality for running arbitrary functions yet. > Thanks for the pointer to ORC -- it looks like the runFunction
2012 Mar 17
3
[LLVMdev] Python bindings in tree
At Fri, 16 Mar 2012 14:12:08 +0100, Christoph Grenz wrote: > > Hello, > > Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc: > > There was some talk on IRC last week about desire for Python bindings to > > LLVM's Object.h C interface. So, I coded up some and you can now find > > some Python bindings in trunk at bindings/python. Currently, the >
2017 Mar 09
2
LLVMGetBitcodeModuleInContext2 problem
Oops, missed initializing some stuff. Added: LLVMLinkInMCJIT(); LLVMInitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); Now it crashes in LLVMGetFunctionAddress(). Hmm. On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote: > Made it a bit further. Here's the current code: > >
2012 Sep 27
0
[LLVMdev] Possible bug or misunderstanding of feature LLVMConstIntOfString
Hi All I am a novice LLVM user trying to use LLVMConstIntOfString using the c api to get a integer of arbitrary size from a hexadecimal string. Example code follows: LLVMContextRef context = LLVMContextCreate(); LLVMValueRef value = LLVMConstIntOfString(LLVMInt64TypeInContext(context), "0x0000000f0000ffff", 16); This is working properly as expected. However I have noticed that
2014 Apr 04
2
[LLVMdev] Weird problems on calling an external function from MCJIT on Windows(mingw)
Hi, I have a IR file generated by Clang: ; ModuleID = 'test_load_lib.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" target triple = "i686-pc-mingw32" declare i32 @a_outside_func(i32) define i32 @test_func() { entry: %call = call i32
2015 Mar 04
2
[LLVMdev] RFC: Better alternative to llvm.frameallocate for use in Windows EH
On Wed, Mar 4, 2015 at 12:36 AM, John McCall <rjmccall at apple.com> wrote: > > On Mar 3, 2015, at 2:25 PM, Reid Kleckner <rnk at google.com> wrote: > > > > I realized that WinEH preparation can probably be a lot less invasive > than it is currently. > > > > Initially, when I was thinking about recovering the address of an object > in a parent stack