search for: llvmdisposemodule

I am, from a front end, calling functions like LLVMModuleCreateWithName, found in Core.h, ultimately calling LLVMWriteBitcodeToFile, found in BitWriter.h. Do I correctly presume, from the existence of LLVMDisposeModule, that I am responsible for calling it when I'm done? Will I need to do deeper disposing myself? I presume at least I will need to free strings I allocated myself, such as the module name I passed in. What about, for example, llvm::DIBuilder::DICreateCompileUnit? I haven't been able so f...

.... More tests, documentation and APIs will follow.] Hi Mahadevan, One more thing I noticed that may be a problem. Automatic finalizers like this one are very dangerous when cooperating with the C++ object model: void dtor_LLVMModuleRef(void *p) { LLVMModuleRef m = (LLVMModuleRef)p; LLVMDisposeModule(m); } Consider the case where a function creates and populates a Module, stuffs it in an ExistingModuleProvider for the JIT, then returns the ModuleProvider, dropping direct reference to the Module. (ModuleProvider takes ownership of the Module.) I presume that your Python object is under...

...nericValueOfInt(int32, 1, 0); LLVMGenericValueRef args[] = {argM, argX, argB}; LLVMGenericValueRef result2 = LLVMRunFunction(jit, func, 3, args); unsigned long long answer = LLVMGenericValueToInt(result2, 0); printf("And the answer is %d\n", (int)answer); LLVMDisposeModule(module); LLVMContextDispose(llvm); return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120425/bb08fbdf/attachment.html>

Hi all, I'd like to announce the availability of Python bindings for LLVM. It is built over llvm-c, and currently exposes enough APIs to build an in-memory IR (and dump it!). It needs LLVM 2.3 latest and Python 2.5 (2.4 should be sufficient, but I haven't tested). Tested only on Linux/i386. Would love to hear your comments. [Needless to say, it's all work in progress, but mostly it

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

...VMCreateGenericValueOfInt(int32, 1, 0); LLVMGenericValueRef args[] = {argM, argX, argB}; LLVMGenericValueRef result2 = LLVMRunFunction(jit, func, 3, args); unsigned long long answer = LLVMGenericValueToInt(result2, 0); printf("And the answer is %d\n", (int)answer); LLVMDisposeModule(module); LLVMContextDispose(llvm); return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120425/d2bd6a0b/attachment.html>

...eWithName("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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100812/388c33da/attachment.html>

Hello, I've been trying to use LLVM's Orc JIT from C API for a few days and i can't get it to work, I'm kind of annoyed for the lack of documentation examples for the C API. Here's my code: https://hasteb.in/ohexiweb.cpp I compile it using clang `llvm-config --cflags --ldflags --libs all` main.c -o main -g -rdynamic And it ends up segfaulting at the line where it calls

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

.../*===-- Modules > -----------------------------------------------------------===*/ > > /* Create and destroy modules. */ > +/** See [llvm::Module::Module]. */ > LLVMModuleRef LLVMModuleCreateWithName(const char *ModuleID); > + > +/** See [llvm::Module::~Module]. */ > void LLVMDisposeModule(LLVMModuleRef M); > > -/* Data layout */ > +/** Data layout. See [Module::getDataLayout]. */ > const char *LLVMGetDataLayout(LLVMModuleRef M); > void LLVMSetDataLayout(LLVMModuleRef M, const char *Triple); > > -/* Target triple */ > +/** Target triple. See [Module::getTarget...

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

In the most basic case, I'd imagine something like this: auto C = std::make_shared<LLVMContext>(); struct ModuleAndSharedContextDeleter { std::shared_ptr<LLVMContext> C; operator()(Module *M) { delete M; } /* ctor to init C */}; std::unique_ptr<Module, ModuleAndSharedDeleter> M(new Module(C.get()), ModuleAndSharedContextDeleter(C)); (or invert this and traffic in structs