search for: llvmdumpmodul

I'm using the llvm-c API and want to use the JIT. I've created the following module ; ModuleID = '_tmp' @a = global i64 5 define i64 @__tempfunc() { entry: %a_val = load i64* @a ret i64 %a_val } This output is generated by LLVMDumpModule just before I call LLVMRunFunction. Which yields a LLVMGenericValueRef. However converting the result to a 64bit integer via LLVMGenericValueToInt(gv, true), it results in 360287970189639680 or something similar - not 5. Converting via LLVMGenericValueToInt(gv, false) didn't help either....

...rsg/llvm-python-bindings/ * 0001-Fix-class-hierarchy-indentation-in-LLVM_FOR_EACH_VAL.patch * 0029-Trivial-copy-paste-error-in-LangRef.patch These are just cosmetic stuff that I stumbled upon * 0004-Add-LLVMPrintModule-to-llvm-c.patch Adds a new LLVMPrintModule function which is similar to LLVMDumpModule but dumps to a string instead of stdout. * 0005-Add-LLVMCreateMemoryBufferFromData-to-llvm-c.patch Adds LLVMCreateMemoryBufferFromData function. * 0015-LLVMMessageRef.patch Adds a "typedef char *LLVMMessageRef;". Which may seem useless. But it acts as documentation. All functions...

...; > > flag = LLVMGetBitcodeModuleInContext2(global_context, module, > &ir_lib_module); > > printf("LLVMGetBitcodeModuleInContext2() returned %d\n", flag); > > LLVMVerifyModule(ir_lib_module, LLVMAbortProcessAction, &error); > LLVMDumpModule(ir_lib_module); > > if (LLVMCreateExecutionEngineForModule(&engine, ir_lib_module, > &error) != 0) { > fprintf(stderr, "failed to create execution engine\n"); > abort(); > } > > // Call the function &...

...MBuildRet(bldr, LLVMConstInt(LLVMInt32Type(), 0, 0)); // Dump Code: printf("\n[llvmPrintf# %s] Verifying Function:\n", moduleName); LLVMVerifyFunction(vFnMain, LLVMPrintMessageAction); printf("\n[llvmPrintf# %s] Dumping LLVM generated Code:\n", moduleName); LLVMDumpModule(modCEx); // Compile and JIT above generated function: LLVMInitializeNativeTarget(); LLVMExecutionEngineRef engExe; char * pErr = NULL; LLVMCreateJITCompilerForModule(&engExe, modCEx, 4, &pErr); if (pErr) { printf("[Creating JIT Compiler] Error: %s\n&q...

...char *err = 0; LLVMMemoryBufferRef ll_f = 0; LLVMModuleRef m = 0; LLVMCreateMemoryBufferWithContentsOfFile("test_load_lib.ll",&ll_f,&err); //read .ll prt(err); LLVMParseIRInContext(LLVMGetGlobalContext(),ll_f,&m,&err); // ll_f doesnt need freeing prt(err); LLVMDumpModule(m); LLVMLinkInMCJIT(); LLVMExecutionEngineRef ee = 0; LLVMCreateMCJITCompilerForModule(&ee,m,0,0,&err); prt(err); using tf_t = int (); tf_t *f = (tf_t*)LLVMGetPointerToGlobal(ee,LLVMGetNamedFunction(m,"test_func")); At first i got "LLVM ERROR: Incompatible obje...

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 > interfaces for Object.h and Disassembler.h are implemented. FYI: I recently startet working on

...> > LLVMCreateMemoryBufferWithContentsOfFile("test_load_lib.ll",&ll_f,&err); > > //read .ll > > prt(err); > > LLVMParseIRInContext(LLVMGetGlobalContext(),ll_f,&m,&err); // ll_f > doesnt > > need freeing > > prt(err); > > LLVMDumpModule(m); > > > > LLVMLinkInMCJIT(); > > LLVMExecutionEngineRef ee = 0; > > LLVMCreateMCJITCompilerForModule(&ee,m,0,0,&err); > > prt(err); > > using tf_t = int (); > > tf_t *f = > > (tf_t*)LLVMGetPointerToGlobal(ee,LLVMGetNamedFunction...

...riggin cool! > My local copy also contain a few patches to llvm-c. > > Everything can be found here: > http://people.0x63.nu/~andersg/llvm-python-bindings/ > > > * 0004-Add-LLVMPrintModule-to-llvm-c.patch > Adds a new LLVMPrintModule function which is similar to > LLVMDumpModule but dumps to a string instead of stdout. > > * 0005-Add-LLVMCreateMemoryBufferFromData-to-llvm-c.patch > Adds LLVMCreateMemoryBufferFromData function. These are desperately needed by the C API. Can you please submit them? FWIW, all my work is at https://github.com/indygreg/llvm/tree/...

Or do you mean I need to load the module into memory before calling LLVMGetBitcodeModuleInContext2? > Yes, you need to load the module into memory first. > LLVMCreateMemoryBufferWithContentsOfFile will do that for you. Thanks! On Wed, Mar 8, 2017 at 3:48 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/8/2017 3:44 PM, Toshiyasu Morita wrote: > > >>

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 interfaces for Object.h and Disassembler.h are implemented. I'd like to stress that things are still rough around the edges, so use at your own risk. I intend to smooth things over in

...ib.ll",&ll_f,&err); > >> > //read .ll > >> > prt(err); > >> > LLVMParseIRInContext(LLVMGetGlobalContext(),ll_f,&m,&err); // ll_f > >> > doesnt > >> > need freeing > >> > prt(err); > >> > LLVMDumpModule(m); > >> > > >> > LLVMLinkInMCJIT(); > >> > LLVMExecutionEngineRef ee = 0; > >> > LLVMCreateMCJITCompilerForModule(&ee,m,0,0,&err); > >> > prt(err); > >> > using tf_t = int (); > >> > tf_t *f =...

...ueRef y; y = LLVMBuildAdd(builder, mx, bParam, "y"); LLVMValueRef retInst; retInst = LLVMBuildRet(builder, y); (void) retInst; LLVMDisposeBuilder(builder); LLVMLinkInJIT(); LLVMLinkInInterpreter(); LLVMInitializeNativeTarget(); LLVMDumpModule(module); /* Now run it! */ LLVMExecutionEngineRef jit = NULL; char *err; // LLVMBool result = LLVMCreateExecutionEngineForModule(&jit, module, &err); LLVMBool result = LLVMCreateJITCompilerForModule(&jit, module, 0, &err); if (result) { prin...

Attached is what I got thus far. What I'm struggling with is proper integration in build system. What is in there is just wild guesses from my side, both on autoconf and cmake variants. It would be great if someone with proper knowledge of the buildsystems could have a look. Also I'm not sure how to properly handle compilation on msvc - clearly "-std=c11 -Wstrict-prototypes" is

...; LLVMValueRef y; y = LLVMBuildAdd(builder, mx, bParam, "y"); LLVMValueRef retInst; retInst = LLVMBuildRet(builder, y); (void) retInst; LLVMDisposeBuilder(builder); LLVMLinkInJIT(); LLVMLinkInInterpreter(); LLVMInitializeNativeTarget(); LLVMDumpModule(module); /* Now run it! */ LLVMExecutionEngineRef jit = NULL; char *err; // LLVMBool result = LLVMCreateExecutionEngineForModule(&jit, module, &err); LLVMBool result = LLVMCreateJITCompilerForModule(&jit, module, 0, &err); if (result) { printf(&qu...

...int main (int argc, const char * argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; char * error = NULL; LLVMExecutionEngineRef engine; LLVMModuleRef module = LLVMModuleCreateWithName("MyModule"); LLVMValueRef toCall = d(module); LLVMDumpModule(module); LLVMLinkInInterpreter(); LLVMCreateInterpreterForModule(&engine, module, &error); LLVMGenericValueRef result = LLVMRunFunction(engine, toCall, 0, NULL); LLVMDisposeModule(module); [pool drain]; return 0; } Thank you, Filip -------------- n...

...include/llvm/Support/Casting.h, line 237. Shouldn't this be a function type? I also can't seem to find how to learn what type it points to - LLVMPointerType() appears to create a new pointer-to-X but is there no getter to find what X is for this pointer in hand? Am on SVN tip on macos. LLVMDumpModule(module) says: ; ModuleID = 'test.bin' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.8.0" @foo = global i32 0...

...printf("args[0]: %d\n", (int)LLVMGenericValueToInt(args[0], 0)); printf("args[1]: %d\n", (int)LLVMGenericValueToInt(args[1], 0)); LLVMGenericValueRef res = LLVMRunFunction(engine, sum, 2, args); printf("result: %d\n", (int)LLVMGenericValueToInt(res, 0)); LLVMDumpModule(mod); // Write out bitcode to file if (LLVMWriteBitcodeToFile(mod, "sum.bc") != 0) { fprintf(stderr, "error writing bitcode to file, skipping\n"); } LLVMDisposeBuilder(builder); LLVMDisposeExecutionEngine(engine); } Here's what I see when I run it: $ ./capi_test...

...oteMemoryToRegisterPass' c:\Work\llvm//fac.c:74: undefined reference to `LLVMAddGVNPass' c:\Work\llvm//fac.c:75: undefined reference to `LLVMAddCFGSimplificationPass' c:\Work\llvm//fac.c:76: undefined reference to `LLVMRunPassManager' c:\Work\llvm//fac.c:77: undefined reference to `LLVMDumpModule' c:\Work\llvm//fac.c:79: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:79: undefined reference to `LLVMCreateGenericValueOfInt' c:\Work\llvm//fac.c:80: undefined reference to `LLVMRunFunction' c:\Work\llvm//fac.c:83: undefined reference to `LLVMGenericValueToInt' c...

...to the interface. So it is easy to add a small proxy over the lib that shows which parts of the llvm-c API that is exercised by the tests. (have that in my bindings) > > * 0004-Add-LLVMPrintModule-to-llvm-c.patch > > Adds a new LLVMPrintModule function which is similar to > > LLVMDumpModule but dumps to a string instead of stdout. > > > > * 0005-Add-LLVMCreateMemoryBufferFromData-to-llvm-c.patch > > Adds LLVMCreateMemoryBufferFromData function. > > These are desperately needed by the C API. Can you please submit them? Will do! > FWIW, all my work is a...