similar to: [LLVMdev] LLVM Ocaml binding

Yeah, that's probably how I'd do it. Might be useful if you guys want to contribute that as a command line option Kevin. -eric On Tue, Jun 24, 2014 at 3:03 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > We do this in Pyston using a JITEventListener that just disassembles the > output; it's "it works let's move on"-quality: >

Jon, I need to create a database of basics blocks and their execution time. The only thing I'm concerned is if a block A is more expensive than a block B. Do you think that even with the overhead I would be able to get the A > B information? Like: overhead + time(A) > overhead + time(B) => A > B. If so, I'm not too much concerned about the accuracy. Not sure if I was clear,

I want to measure the performance of a JITed code snippet on MCJIT. so I was planning to inject the RDPMC inst for the code generated through a llvm IR builder. Is there a patch available ? If there's a better way to do it please chime in. Thanks sathvik -------------- next part -------------- An HTML attachment was scrubbed... URL:

I believe the perf tool cannot profile/analyze the JITed code in MCJIT model. Can you please confirm this ? I was working on a patch to fix this. Another question, is the there any support to map the llvm IR with x86 generated assembly ? so its easier to analyze the code generator. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Dear Users, Recently I have started using HINT option in Asterisk 1.2.4 with my Polycom 500 phone. What I have notice that for a day or two everything is working great but then HINTs stop working on my Polycom phone. It also happens when I reload asterisk from console. I do sip debug and I do not see anymore asterisk sending NOTIFY messages about my watched extension. To make it work again I

Hi all, I have successfully compiled the libguestfs-1.0.89 source and 'make install'ed on my Fedora 12 box. Everything went fine. I have ocaml installed so the default configuration enabled ocaml binding. then I found some minimal configure mistake with my compilation and wanted to compile and install again. 1.first I made uninstall and cleaned up everthing: $ make uninstall $ make clean

Hello all, I am in the process of adding a new return type for the hivex ABI, and I found what I think is an error. I'm not sure, because I don't understand the OCaml binding data structures. Can somebody inform me if the patch below actually corrects a problem? --Alex --- generator/generator.ml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

Hi all, I'm considering using ocaml for some experiments I want to try -- does the binding currently support reading existing bitcode, or just generating it? I want to try out some program transformation ideas that would probably be rather easier to express in ocaml than C++. Thank you in advance, Sarah Thompson

On Dec 10, 2007, at 16:52, Sarah Thompson wrote: > I'm considering using ocaml for some experiments I want to try -- > does the binding currently support reading existing bitcode No, but it's easily added… — Gordon

> Is it reasonable for me to hack on this, or would you rather do it > yourself? (If the latter, you would be very much in my debt...) Or the other way around, or something. :) [s]

On 2007-12-10, at 18:04, Sarah Thompson wrote: > >> Is it reasonable for me to hack on this, or would you rather do it >> yourself? (If the latter, you would be very much in my debt...) > > Or the other way around, or something. :) :) I'm adding it now. — Gordon

On Monday 10 December 2007 23:52, Gordon Henriksen wrote: > On 2007-12-10, at 18:28, Jon Harrop wrote: > > Incidentally, should more OCaml stuff beyond the bindings be part of > > LLVM or would it be better to fork them into a separate project > > Can you be more specific than "stuff"? I'm thinking of a library that compiles an AST represented by an OCaml data

On Dec 12, 2007, at 08:16, Jon Harrop wrote: > On Monday 10 December 2007 23:52, Gordon Henriksen wrote: > >> On 2007-12-10, at 18:28, Jon Harrop wrote: >> >>> Incidentally, should more OCaml stuff beyond the bindings be part >>> of LLVM or would it be better to fork them into a separate project >> >> Can you be more specific than

On Wednesday 12 December 2007 13:39, Gordon Henriksen wrote: > Since that ASTs are by definition language-specific, such should > probably be a separate project because LLVM itself is language-agnostic. Well, I'd like this to factor out commonality from the implementations of all managed languages (everything from C++ to Lisp) so I think it should express a typed language with typical

On Dec 12, 2007, at 08:59, Jon Harrop wrote: > Well, I'd like this to factor out commonality from the > implementations of all managed languages (everything from C++ to > Lisp) so I think it should express a typed language with typical > control-flow constructs (including exceptions), only first-order > functions and parametric polymorphism/generics. The generics should

On Wednesday 12 December 2007 23:30, Gordon Henriksen wrote: > Hi Jon, > > In this direction, PyPy and Reid's HLVM projects may be of interest to > you. Yes. I've had a look at both of those but they only seem to cater for dynamically-typed languages. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

On Mar 4, 2008, at 09:18, Gordon Henriksen wrote: > Hi Erick, > > Thanks, this looks good. Can you please resubmit this patch, and the > others, as an attachment? > > On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > >> diff --git include/llvm-c/Core.h include/llvm-c/Core.h >> index 9b11df5..3676377 100644 >> --- include/llvm-c/Core.h >> +++

I've partially ported the OCaml bindings to support LLVMContext, and I wanted to get people's opinion on how to implement it in the API. For the LLVM's C++ api, many key functions were modified to only take a LLVMContext, such as replacing the global variable Type::FloatTy with a function Type::getFloatTy(LLVMContext&). For llvm-c though, we need to maintain backwards compatibility

everyone-- This time, it's to correct an error in the type of the Llvm.dispose_context function. I made this patch against the trunk revision 94296. -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-ocaml-02.patch Type: application/octet-stream Size: 1263 bytes Desc: not available URL:

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/