similar to: [LLVMdev] Last chance to get anything into llvm-c and ocaml bindings

On Fri, Mar 5, 2010 at 5:53 AM, George Giorgidze <giorgidze at gmail.com> wrote: > > Hi Erick, > > Can you make the following functions available in llvm-c. > > createStandardFunctionPasses > createStandardModulePasses > createStandardLTOPasses > > Thanks in advance, George This is a little tricky, so I need some advice from the community. First off, I'm

Erick Tryzelaar <erick.tryzelaar <at> gmail.com> writes: > > I've pretty much finished exposing all I wanted to llvm-c and the > ocaml bindings for the soon to be released 2.7. Does anyone need any > other functions exposed before the code freeze on the 7th? > Hi Erick, Can you make the following functions available in llvm-c. createStandardFunctionPasses

On Mar 3, 2010, at 20:44, Erick Tryzelaar wrote: > > I've pretty much finished exposing all I wanted to llvm-c and the > ocaml bindings for the soon to be released 2.7. Does anyone need any > other functions exposed before the code freeze on the 7th? Oh hey... I remember now. There is one thing I probably won't get around to doing myself until after the code freeze. (*

Hello, I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes. - I am using the official release of LLVM 2.8 - I have compiled LLVM with threading enabled; I am running llvm::llvm_start_multithreaded() on

On Tue, Mar 22, 2011 at 11:51 AM, Peter Zion <peter.zion at fabric-engine.com> wrote: > Hello, > > I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes. > > - I am using the official

On Feb 18, 2010, at 12:51, Erick Tryzelaar wrote: > > I'm in the process of finishing up the ocaml llvm bindings, and I had > some last minute questions before we code freeze: > > 1. What version of ocaml is everyone using, and how old of an ocaml > version do you need to support? Still using OCaml 3.11.1, but will but upgrading to OCaml 3.11.2 around the same time as the

> Date: Wed, 26 Oct 2011 11:52:50 -0700 > From: Tanya Lattner <lattner at apple.com> > Subject: [LLVMdev] Release Notes: Volunteers needed > We need some volunteers to help with the 3.0 release notes. Traditionally, Chris has been the one to go > through all the commits (6 months worth!) and come up with a concrete list of things that have changed in 3.0. > Ideally,

I'm in the process of finishing up the ocaml llvm bindings, and I had some last minute questions before we code freeze: 1. What version of ocaml is everyone using, and how old of an ocaml version do you need to support? 2. Would it be alright if I renamed some functions? Module providers are being removed for 2.7. I can keep the old functions around, but I'd prefer to keep the API clean.

(ccing llvmdev) Hi Ranjit! I only ported Chris's tutorial and Gordon did the vast majority of the bindings, so they deserve most of the praise. I believe there are techniques for walking over the CFG. You can load up code using Llvm_bitreader, use things like Llvm.iter_globals, Llvm.iter_functions, and Llvm.iter_instrs to walk over the module, and write out a new llmodule using

On 6 janv. 2011, at 19:00, llvmdev-request at cs.uiuc.edu wrote: >> I'm using LLVM to JIT-compile the XL programming language. I've recently added a whole-program optimization phase that gives excellent results, but I noticed that the StripDeadPrototypesPass was removing all references to my runtime support functions. > > why is that a problem? Because I have pointers to

Hi, In my application I am JITing thousands of functions, though I am doing it sequantially and running only one at a time. So it is crucial to be able to properly clean up the memory from an old JITed function when JITing and running the new one. I am using Haskell binding of LLVM and my application works OK. However, memory usage increases and never decreases during the run time of my

Thanks. The reason I ask is because I'm looking at some code that does just that. A single FunctionPassManager is constructed with a dummy Module and createStandardFunctionPasses is called on it. The FunctionPassManager cached and run on Functions in other Modules. So far I haven't noticed any problems but I guess that is because the passes added by createStandardFunctionPasses don't

everyone-- I notice that Llvm.llvm_handle_to_type is actually defined to create a type handle from a type, rather than vice versa as its name would imply. Should I send a patch to change the name of the function to reflect its type better, or should I just lump it? — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

Hi, I need to add switches like -disable-mem2reg, disable-gvn to llvm-ld. Currently CreateStandardLTOPasses takes in only DisableInternalize and DisableInliner switches. Is modifying this API okay for these new switches, or is it doable in some other ways ? - Sanjiv

everyone-- I'm trying to build LLVM-GCC as a cross-compiler for a new target. I've successfully patched binutils, the FSF GCC, LLVM and Clang to build for this new target-- they work fine, but the LLVM-gcc build is failing for me. All my llvm.org sources are tracking the Subversion trunk, but my problem is probably not related to any ongoing churn there. I'm doing something

Hi, Was this ever resolved? I'm curious, I'm also in a situation where there may be many (very many) JITted functions over the history of an application (which may be running for many days) Thanks On Mar 20, 2009, at 7:34 AM, George Giorgidze wrote: > Hi, > > In my application I am JITing thousands of functions, though I am > doing it sequantially and running only

everyone-- I don't know whether this is a bug or not. I'm trying to bootstrap an embedded application and using LLVM tools to generate the assembly code, which I then assemble and link with traditional tools. The bootstrap loader, of course, runs in a very limited environment, and I have to roll my own memcpy() function for it, i.e. there is no kernel, nothing at all, this stuff

everyone-- The OCaml bindings need help again. diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800 @@ -42,13 +42,18 @@ | External | Available_externally | Link_once + | Link_once_odr | Weak +

everyone-- File this under Advocacy. See this thread <http://www.haskell.org/pipermail/glasgow-haskell-users/2010-February/018425.html> for more information, but the short summary is that they're deprecating their old "compile to GCC" backend in favor of David Terei's new LLVM backend. They're still planning for their C-- backend to be the primary backend for native

Chris Lattner wrote: > On Feb 9, 2010, at 7:39 PM, Sanjiv Gupta wrote: > > >> Hi, >> I need to add switches like -disable-mem2reg, disable-gvn to llvm-ld. >> Currently CreateStandardLTOPasses takes in only DisableInternalize and >> DisableInliner switches. >> >> Is modifying this API okay for these new switches, or is it doable in >> some