search for: llvmdisposemessage

...mp;options, sizeof(options)); options.OptLevel = MODULE_OPT_LEVEL; /* 3 of 0 */ options.CodeModel = LLVMCodeModelJITDefault; if (LLVMCreateMCJITCompilerForModule(&qry->llvm.engine, qry->llvm.mod, &options, sizeof(options), &error) != 0) { fprintf(stderr, "%s\n", error); LLVMDisposeMessage(error); abort(); } LLVMRunStaticConstructors(qry->llvm.engine); Then I do the IR building and get the function pointer i need: iter->run = LLVMGetPointerToGlobal(qry->llvm.engine, func_ref); Am i doing something wrong? Thanks -- Regards, Konstantin -------------- next part ----------...

...Ref builder = LLVMCreateBuilder(); LLVMPositionBuilderAtEnd(builder, entry); LLVMValueRef tmp = LLVMBuildAdd(builder, LLVMGetParam(sum, 0), LLVMGetParam(sum, 1), "tmp"); LLVMBuildRet(builder, tmp); char* error = NULL; LLVMVerifyModule(mod, LLVMAbortProcessAction, &error); LLVMDisposeMessage(error); LLVMExecutionEngineRef engine; error = NULL; LLVMLinkInMCJIT(); LLVMInitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); if (LLVMCreateExecutionEngineForModule(&engine, mod, &error) != 0) { fprintf(stderr, "failed to c...

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

...ptions.OptLevel = MODULE_OPT_LEVEL; /* 3 of 0 */ > options.CodeModel = LLVMCodeModelJITDefault; > > if (LLVMCreateMCJITCompilerForModule(&qry->llvm.engine, qry->llvm.mod, > &options, sizeof(options), &error) != 0) { > fprintf(stderr, "%s\n", error); > LLVMDisposeMessage(error); > abort(); > } > LLVMRunStaticConstructors(qry->llvm.engine); > > Then I do the IR building and get the function pointer i need: > > iter->run = LLVMGetPointerToGlobal(qry->llvm.engine, func_ref); > > > Am i doing something wrong? > > Thanks &gt...

...:48: undefined reference to `LLVMBuildPhi' c:\Work\llvm//fac.c:51: undefined reference to `LLVMAddIncoming' c:\Work\llvm//fac.c:52: undefined reference to `LLVMBuildRet' c:\Work\llvm//fac.c:54: undefined reference to `LLVMVerifyModule' c:\Work\llvm//fac.c:55: undefined reference to `LLVMDisposeMessage' c:\Work\llvm//fac.c:59: undefined reference to `LLVMCreateModuleProviderForExistingModule' c:\Work\llvm//fac.c:61: undefined reference to `LLVMCreateJITCompiler' c:\Work\llvm//fac.c:64: undefined reference to `LLVMDisposeMessage' c:\Work\llvm//fac.c:68: undefined reference to `LLV...

...e the dependency. > #include <stddef.h> > > extern const char* > lto_get_error_message(); I've tried not to create thread-unsafe designs in the rest of the bindings. I return a malloced error message by optional output parameters and provide a generic dispose function (LLVMDisposeMessage). Copying CFError's design might be smarter still. > extern bool > lto_module_is_object_file_in_memory(const uint8_t* mem, size_t > length); > > extern bool > lto_module_is_object_file_in_memory_for_target(const uint8_t* mem, > size_t length, >...

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

...ompile 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", pErr); LLVMDisposeMessage(pErr); exit(0); } LLVMPassManagerRef rPassMgr = LLVMCreatePassManager(); LLVMAddTargetData(LLVMGetExecutionEngineTargetData(engExe), rPassMgr); LLVMAddConstantPropagationPass(rPassMgr); LLVMAddInstructionCombiningPass(rPassMgr); LLVMAddPromoteMemoryToRegisterPass(rP...

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

...eModuleProvider *LLVMModuleProviderRef; > > /* Used to provide a module to JIT or interpreter. > - * See the llvm::MemoryBuffer class. > + * See the [llvm::MemoryBuffer] class. > */ > typedef struct LLVMOpaqueMemoryBuffer *LLVMMemoryBufferRef; > > @@ -165,18 +165,21 @@ void LLVMDisposeMessage(char *Message); > /*===-- Modules > -----------------------------------------------------------===*/ > > /* Create and destroy modules. */ > +/** See [llvm::Module::Module]. */ > LLVMModuleRef LLVMModuleCreateWithName(const char *ModuleID); > + > +/** See [llvm::Module::~M...

...;stddef.h> >> >> extern const char* >> lto_get_error_message(); > > I've tried not to create thread-unsafe designs in the rest of the > bindings. I return a malloced error message by optional output > parameters and provide a generic dispose function > (LLVMDisposeMessage). Copying CFError's design might be smarter still. There are other things not thread safe about the API. Adding a string return would complicate the API. And it is possible to make the API thread safe in the future by making lto_get_error_message() return a per-thread string. > &gt...

--- 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:

Hello. I work at Apple on our linker. We are working to improve support for llvm in our tools. A while back Devang created <llvm/LinkTimeOptimizer.h> a C++ interface which allows the linker to process llvm bitcode files along with native mach-o object files. For the next step we'd like our other tools like nm, ar, and lipo to be able to transparently process bitcode files

...-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 that return a string that should be freed with LLVMDisposeMessage are changed to use this type instead. * bindings-python.tar.gz The bindings/python/ directory. There are some hardcoded paths and hacks here and there.