search for: llvmmoduleref

...ore.h > @@ -48,20 +48,20 @@ extern "C" { > > /** > * The top-level container for all other LLVM Intermediate > Representation (IR) > - * objects. See the llvm::Module class. > + * objects. See the [llvm::Module] class. > */ > typedef struct LLVMOpaqueModule *LLVMModuleRef; > > /** > - * Each value in the LLVM IR has a type, an instance of [lltype]. > See the > - * llvm::Type class. > + * Each value in the LLVM IR has a type, an instance of > [LLVMTypeRef]. See the > + * [llvm::Type] class. > */ > typedef struct LLVMOpaqueType *LLVM...

On 2008-05-13, at 02:12, Mahadevan R wrote: >>> That's not how the object works... > > Gordon, I think I can make it work if we have the following additional > function in LLVM-C: > > LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) { > return wrap(unwrap(MP)->getModule()); > } Can I ask, how general is your solution? I only intended to use this particular example as a proxy for the general problem of interaction between GC and manual memory management being complex. Will...

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

...<gordonhenriksen at mac.com> wrote: > On 2008-05-13, at 02:12, Mahadevan R wrote: > > >>> That's not how the object works... > > > > Gordon, I think I can make it work if we have the following additional > > function in LLVM-C: > > > > LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) { > > return wrap(unwrap(MP)->getModule()); > > } > > Can I ask, how general is your solution? I only intended to use this > particular example as a proxy for the general problem of interaction > between GC and manual memory m...

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

...wrote: >> On 2008-05-13, at 02:12, Mahadevan R wrote: >> >>>>> That's not how the object works... >>> >>> Gordon, I think I can make it work if we have the following >>> additional >>> function in LLVM-C: >>> >>> LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) { >>> return wrap(unwrap(MP)->getModule()); >>> } >> >> Can I ask, how general is your solution? I only intended to use this >> particular example as a proxy for the general problem of interaction >> between GC and...

..., it's all work in progress, but mostly it works as > expected. 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 ta...

...estruction of modules that are attached to MPs, or 2b) Do not do anything in the dtors of MPs (while letting the dtor of modules do the work) Both options have the disadvantage of assuming the C/C++ implementation (like MP::dtor deletes only the module and nothing else). > The routine LLVMModuleRef > LLVMGetGlobalParent(LLVMValueRef Global); poses a related problem; in this > case, the returned reference is non-owning, so you must not dtor it from > Python. If I do this: m1 = Module.new() g1 = m1.add_global_variable(ty, "name") m2 = g1.module will the LLVMModuleRef...

I'm trying to use LLVMGetBitcodeModuleInContext2 to load a .bc file. However, it's not working. The code looks something like this: void llvm_load_IR_library(char *path) { LLVMContextRef global_context; LLVMMemoryBufferRef module_path; LLVMModuleRef ir_lib_module; bool flag; module_path = LLVMCreateMemoryBufferWithMemoryRange(path, strlen(path), "path", 1); global_context = LLVMGetGlobalContext(); flag = LLVMGetBitcodeModuleInContext2(global_context, module_path, &ir_lib_module); printf...

Hi, I stumbled across the following: > /* Builds a module from the bitcode in the specified memory buffer, > returning a > reference to the module via the OutModule parameter. Returns 0 on success. > */ > LLVMBool LLVMParseBitcode2(LLVMMemoryBufferRef MemBuf, > LLVMModuleRef *OutModule); However in most scenarios i know, a Bool is something like 0 = False !0 = True In short: is it just me or is this really counterintuitive? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160912...

...the dtor of > modules do the work) The ModuleProvider itself also needs to be destroyed or you have a memory leak. > Both options have the disadvantage of assuming the C/C++ > implementation (like MP::dtor deletes only the module and nothing > else). > >> The routine LLVMModuleRef LLVMGetGlobalParent(LLVMValueRef Global); >> poses a related problem; in this case, the returned reference is >> non-owning, so you must not dtor it from Python. > > If I do this: > > m1 = Module.new() > g1 = m1.add_global_variable(ty, "name") > m2 = g...

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

...ically calls the wrapper C funtcion _w ## func. So when we use LLVMAddFunction methoed in python, it actually calls _wLLVMAddFunction. Then how is _wLLVMAddFunction defined? Also in *_core.c* file, there is such a statement that is related to LLVMAddFunction: *_wrap_objstrobj2obj(LLVMAddFunction, LLVMModuleRef, LLVMTypeRef, LLVMValueRef) * This macro is defined in wrap.h file: */** * Wrap LLVM functions of the type * outtype func(intype1 arg1, const char *arg2, intype3 arg3) */ #define _wrap_objstrobj2obj(func, intype1, intype3, outtype) \ static PyObject * \...

...aming prefix is LLVM, > which may be a bit long. (Would LL be better?) LLVM seems fine to me, and the naming convention seems ok (using lowercase + underscores makes the name longer). I do find things like this slightly strange: /* Same as Module::addTypeName. */ int AddTypeNameToModule(LLVMModuleRef M, const char *Name, LLVMTypeRef Ty); I'd expect it to be named something like "LLVMModuleAddTypeName" or something, using NamespaceClassMethod uniformly. > Pointers are opaque, obviously. I find myself copying enums, which > is mildly scary. Copying the enums does seem...

Hi everybody, I'm currently working with LLVM (v 2.6) and I try to interpret LLVM bitcode using the c API. Here is my problem : I have two LLVMModuleRef, M1 and M2, M1 contains the function "funct()" and M2 contains a main function which call "funct()" (M2 declares "funct()" too but it doesn't define it). If I try to run the main function, I got the error "LLVM ERROR: Tried to execute unknown external function...

On Mon, May 12, 2008 at 9:50 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On May 12, 2008, at 12:00, Mahadevan R wrote: > > > 1) The MP dtor does a no-op (deletes self, but not the module it owns) > > That's not how the object works... Yes, I know ;-) I was hoping you could add a detach() or some such API for the MP...

> > That's not how the object works... Gordon, I think I can make it work if we have the following additional function in LLVM-C: LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) { return wrap(unwrap(MP)->getModule()); } Do you think you could add that? Can I send you a patch? Thanks & Regards, -Mahadevan.

...Here's the current code: > > void llvm_load_IR_library(char *path) > { > char *error; > LLVMExecutionEngineRef engine; > object0_t* (*func)(void), *output; > LLVMContextRef global_context; > LLVMMemoryBufferRef module; > LLVMModuleRef ir_lib_module; > bool flag; > > printf("loading IR library from path: %s\n", path); > > LLVMCreateMemoryBufferWithContentsOfFile(path, &module, &error); > > global_context = LLVMGetGlobalContext(); > > flag = LLVMG...

...define i8* @MyFunction() { entrypoint: %myCall = call i8* @NSFullUserName() ; <i8*> [#uses=1] ret i8* %myCall } Where am I going wrong here? To add some code to my previous question: LLVMTypeRef i8Ptr(void) { return LLVMPointerType(LLVMInt8Type(), 0); } LLVMValueRef d(LLVMModuleRef module) { LLVMValueRef result; LLVMBasicBlockRef block; LLVMBuilderRef builder = LLVMCreateBuilder(); LLVMValueRef fullUsername = LLVMAddFunction(module, "NSFullUserName", LLVMFunctionType(LLVMPointerType(LLVMInt8Type(), 0), NULL, 0, 0)); LLVMSetLinkage(fullUserna...