similar to: [LLVMdev] LLVM C bindings

Corrado Zoccolo wrote: > Unfortunately, it seems that llvm-c interface lacks major > functionalities, e.g. getting a pointer to a jit-ted function. > It is easy to write a small c++ wrapper to expose the functionality > that one wants (llvm-py does it for the many optimization passes not > available through c binding), but I wonder if it is possible to have a > simpler &

Hi, I find the C bindings for LLVM very useful, since they allow to invoke LLVM from a wider set of software tools (i.e. llvm-py uses it to export llvm to python). Unfortunately, it seems that llvm-c interface lacks major functionalities, e.g. getting a pointer to a jit-ted function. It is easy to write a small c++ wrapper to expose the functionality that one wants (llvm-py does it for the many

On Mar 11, 2009, at 2:39 PM, Corrado Zoccolo wrote: > I don't know how to file a PR, but I have a patch (see below), that > should work regardless of abi differences, since it relies on the > compiler to do the though job. > > void X86CompilationCallback_SSE(void) { > char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned How do you ensure it's 16-byte

It looks fine to me. Anton, does it look ok to you? Evan On Mar 20, 2009, at 2:33 PM, Corrado Zoccolo wrote: > I've created a patch (attached to the bug): > http://llvm.org/bugs/attachment.cgi?id=2744, that goes in a different > direction, and solves the safety problems. > The patch uses original asm, but removes the call through plt, and > puts the invoked function in an

I don't know how to file a PR, but I have a patch (see below), that should work regardless of abi differences, since it relies on the compiler to do the though job. void X86CompilationCallback_SSE(void) { char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned asm volatile ( "movl %%eax,(%0)\n" "movl %%edx,4(%0)\n" // Save EAX/EDX/ECX

On Linux x86_64, it is different. The x86-64 ABI says (http://www.x86-64.org/viewvc/trunk/x86-64-ABI/low-level-sys-info.tex?revision=84&content-type=text%2Fplain): >> The end of the input argument area shall be aligned on a 16 byte boundary. In other words, the value (%rsp - 8) is always a multiple of 16 when control is transferred to the function entry point. The stack pointer, %rsp,

Hi Evan > It looks fine to me. Anton, does it look ok to you? This looks ok for me modulo win64+vcpp issues, which I mentioned in the PR (external .asm files). The anonymous namespace thing should be guarded by define (either _M_AMD64 or X86_64_JIT && _MSC_VER, I'd prefer the latter). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint

Hello, Simon > So far, i found no way to denote calls to the host function as aligned > or maintain stack alignment throughout the stack frame of the jit > compiled function. Further, the gcc front end (llvm-g++ (GCC) 4.2.1) > seems to ignore directives such as -mpreferred-stack-boundary. Mike is right. It depends on your subtarget: 1. If you're running stuff on Darwin, which has

Hi all, i am trying to call an aligned function in my host application from jit compiled bitcode. The call itself is done using an absolute pointer to the function. The host application's functions make heavy use of SSE instructions and are thus operate on a stack aligned to 16 byte. If i call an aligned function in the host application from a frame running jit compiled code, the alignment

On Thu, Mar 12, 2009 at 5:18 PM, Dan Gohman <gohman at apple.com> wrote: > This looks like an interesting idea. As written, the inline asms > aren't safe > though; they reference %eax, %edx, etc. without declaring such things in > constraints, so the compiler wouldn't know that it can't clobber those > registers. > > Dan > I don't know how to specify

I've created a patch (attached to the bug): http://llvm.org/bugs/attachment.cgi?id=2744, that goes in a different direction, and solves the safety problems. The patch uses original asm, but removes the call through plt, and puts the invoked function in an anonymous namespace. This allows the static linker to always know the location of the jump, removing the need for PIC invocation setup. This

Hi, I found that on my system: $ uname -a Linux tintoretto 2.6.23.8cz #1 SMP Fri Nov 23 17:07:39 CET 2007 x86_64 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GNU/Linux $ cat /etc/redhat-release Mandriva Linux release 2008.0 (Official) for x86_64 I can't execute functions Jitted by LLVM that call back functions in the main program, if the jit is run from a .so library. I replaced LLVM with

Hi again, >From a .so, I'm doing the following: * I create an empty Module, declare some functions (from the main executable) and add a global mapping for them. * Then I create a jitted function that calls those global functions * and I call it. The JITted function segfaults because x86_64 JIT creates a call with 32bit relative address to rip, while the called function is outside reach.

Hello. I found that the X86CompilationCallback_SSE wrapper for X86CompilationCallback2 is not setting up properly for the PIC invocation. Before you can correctly invoke a function via the Procedure Linkage Table (plt), the ABI mandates that ebx is pointing to the GOT (Global Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) Dump of assembler code for function

I am just considering various different designs for the code emitted by a HLVM and one alluring approach is to make all local variables immutable and replace loops with (tail) recursive functions. This makes it much easier to reason about injected code such as GC checks. However, I am concerned about the performance of the generated code. Specifically, this is likely to result in small

On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote: > Does anyone know if there is any realistic project using LLVM-OCaml > Bindings? I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings: http://www.ffconsultancy.com/ocaml/hlvm/ There are at least two other significant users of LLVM's OCaml bindings, AFAIK. > How is the performance? Performance

I'm cc:-ing my reply to xapian-devel, since others may have an opinion. In particular, James has probably done most work on the python bindings. On Fri, Jan 27, 2006 at 03:56:23PM -0800, Jason Toffaletti wrote: > I'm curious if boost::python has been considered for creating more > pythonic bindings to Xapian. I've used it to wrap several C++ libraries > and found the

On Tue, Feb 16, 2010 at 2:47 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote: >> Does anyone know if there is any realistic project using LLVM-OCaml >> Bindings? > > I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings: > >  http://www.ffconsultancy.com/ocaml/hlvm/ > > There

Attached are updated LLVM-OCaml Bindings Tutorial from Chris Wailes. (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-April/021804.html) We changed them to work with the latest APIs(LLVM2.6 and the latest LLVM from SVN). Does anyone know if there is any realistic project using LLVM-OCaml Bindings? How is the performance? Jianzhou -------------- next part -------------- A non-text attachment was

I recently wrote a post on installing "Git for Windows" on a legacy XP SP3 Home box. http://nurmi-labs.blogspot.com/2016/11/git.html I added some missing files from the MSYS2 packages which were removed for the downloadable "Git for Windows" installer and a compiler and some additional libraries. For other utilities (bison, flex, info, m4, make, and csh/tcsh), and code I