similar to: [LLVMdev] [Caml-list] Pattern-matching destructors ?

Hi, I was able to try this on linux again. Unfortunately it doesn't work at all (neither using runFunction nor a CallInst). It simply says function called get5 not known. Calling printf the same way works, though. On linux the function is exported as "get5" from the executable while it is called "_get5" on OS X. I could not spot any other differences.. any

Hi, > I know nothing about this, but the failed assertion suggests the PPC > code generator can't cope with a constant that's bigger than > expected at > that point. Have you taken a look at PPCJITInfo.cpp:382? It may shed > some light. It's inside PPCJITInfo::relocate but unfortunately I could not figure out anything from the source. It looks like it's

On Tue, 12 Jun 2007, Jan Rehders wrote: >> Jan, how are you doing this? Are you creating an external LLVM >> Function object named "get5", then using EE::addGlobalMapping? If >> 'get5' exists in the address space, why not just let the JIT resolve it >> (which will then create the stub)? > > Yes. I create a Function with matching signature,

Hi, when upgrading my compiler from LLVM 2.1 to 2.4 I stumbled upon a change of behaviour in ParseAssemblyString. For an interactive toplevel I am generating .ll source and feeding it into ParseAssemblyString like this: Module* parsedModule = ParseAssemblyString( code, targetModule, &errorInfo ); where targetModule is the module I expect all the LLVM code to go. Until 2.1 the

Jon, >> . Some interface to LLVM from OCaml >> >> What work has already been done on this and similar ideas? What is >> the >> easiest >> way to interface a front-end written in OCaml with an LLVM backend? I've written a compiler front end for a custom language in OCaml which features compilation and an interactive toplevel. Until now I am

Hello, can anyone help me calling native functions from LLVM-Bytecode functions run in the JIT? I have a program which creates an LLVM execution engine and adds modules and functions to it on the fly. I need to call some native functions of my program from bytecode functions which causes some troubles as it appears not to be documented. My test scenario works like the following: I have

On 2007-10-02, at 10:46, Jan Rehders wrote: > where can I read more about this? I assume (hope) the lib provides > some kind of OCaml bindings? I could not find any trace of it in > the 2.1 release source so I guess it's currently SVN only? Jan, Here's a trivial example. $ cat metahelloworld.ml (* metahelloworld.ml *) open Llvm open Llvm_bitwriter let _ = let filename

Hi, > Okay. If the function exists in your application's address space > already, > just name the LLVM function the same name as the native function > and the > JIT should find it an do the right thing. This is how it finds > printf and > a variety of other things. You don't need to call addGlobalMapping at > all. Looking at the output of "nm

Hi, where can I read more about this? I assume (hope) the lib provides some kind of OCaml bindings? I could not find any trace of it in the 2.1 release source so I guess it's currently SVN only? greetings, Jan On 2. Okt 2007, at 12:22, Gordon Henriksen wrote: > On 2007-10-02, at 03:19, Gordon Henriksen wrote: > >> On Oct 2, 2007, at 00:17, Bill Wendling wrote: >>

Hi, attached is a small testcase I did. It builds two LLVM functions which both call two native functions get5 and get6. The native functions are in the exe and in the dll. On OS X it works like a charm. On Linux none of the two functions can be called. Maybe someone can try them or have a look at it to see if there is something obviously wrong greetings, Jan -------------- next part

Hi, how do I compile LLVM for 64-bit on OS X? I want to get 64-bit libraries which generate x86_64 to link them into a 64-bit application. All my attempts ended up with either 32-bit libraries or errors. My machine is an Intel Xeon quad core, 'sysctl hw.cpu64bit_capable' returns 1 so I think the machine is fine. - './configure && make' yields 32-bit libraries and

Hallo, we are trying to extend the R package multcompView in agreement with the author Hans-Peter Piepho. The function multcompLetters implements so far a heuristic. We would like to add a function that implements an exact algorithm and returns a provable optimum result. This algorithm has been implemented in Objective Caml and we would like to reuse this code. We wrote an R function

On Dec 23, 2008, at 7:15 AM, Jan Rehders wrote: > Hi, > > when upgrading my compiler from LLVM 2.1 to 2.4 I stumbled upon a > change of behaviour in ParseAssemblyString. For an interactive > toplevel I am generating .ll source and feeding it into > ParseAssemblyString like this: Hi Jan, I don't think that there is any intentional change here. It sounds like a bug.

On 11 Jun 2007, at 22:35, Jan Rehders wrote: > It's inside PPCJITInfo::relocate but unfortunately I could not figure > out anything from the source. It looks like it's calculating new > addresses for functions which does not make much sense for a native > function, at all On the PPC, unconditional branches are limited to 24 bit signed displacements. When you call a function

On Monday 26 November 2007 19:30, Gordon Henriksen wrote: > It might be exciting to have an Ocaml with "exec" (surely it would > allow new classes of programs), but static compilation seems clearly > superior for existing programs, so my focus is there for now. There are various different approaches to this, of course, but having tried the Lisp and MetaOCaml approaches I think

On Nov 29, 2007, at 1:24, Chris Lattner <sabre at nondot.org> wrote: > int x = ... > try { > x++; > foo(); > > use (x); > > } catch (...) { > print x; > } > > Because the 'throw' doesn't restore the callee-save registers as the > stack is unwound, the compiler can't put X in a register across the x+ > + and use of x

On Nov 28, 2007, at 10:16 PM, Gordon Henriksen wrote: >> It only works if values are not held in registers across throws >> though, which is kinda lame ... > > > Though I'm primarily interested in this model only from an > interoperability perspective, reloading the register file for a throw > seems a comparatively small price to pay compared to, say, >

On Tue, 27 Nov 2007, Gordon Henriksen wrote: > As Daniel Berlin pointed out on IRC, the language model is trivial. It has > just three exception-handling primitives: > raise expr > try expr with matching > exception id ( tuple-type-expr )? ok. > The codegen for raise is simple. It just reads a saved return address from > the caml_exception_pointer global and returns

On 2007-10-02, at 03:19, Gordon Henriksen wrote: > On Oct 2, 2007, at 00:17, Bill Wendling wrote: > >> I get this error duing a "make install": >> >> llvm[3]: Installing Debug /usr/local/lib/ocaml/libllvm.a >> install: /usr/local/lib/ocaml/libllvm.a: Permission denied >> make[3]: *** [install-a] Error 71 >> make[2]: *** [install] Error 1

On Nov 26, 2007, at 11:30 AM, Gordon Henriksen wrote: >> >> Of course, I do know that there are some typing issues and >> theoritical points which I deliberately ignore here. I'm supposing >> the guy wanting to LLVM for Ocaml is knowing that he seeks trouble. > > The ocaml type system is easily represented in LLVM. The only real > mismatches I'm aware of