search for: czoccolo

...ly generating C bindings from c++ classes. Or am I missing some obvious way to have the aforementioned functionality in C without writing wrappers? Thanks, Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo at gmail.com PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

...not if linking it to the main executable (the main executable is 'perl' in my test case, as I'm working on jitting perl opcodes from a module). Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo at gmail.com PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

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

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

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

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

...________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo at gmail.com PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

...the compilation callback is handed to a function residing in a different .so library, and called from there (e.g. if called from python's ctypes ffi). Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo at gmail.com PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

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

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

On Mon, 16 Feb 2009 21:18:48 +0000 Jon Harrop <jon at ffconsultancy.com> wrote: > > On Monday 16 February 2009 20:04:38 Paul Melis wrote: > Yes. I similarly found that tail calls, sret and parts of first-class structs > are not usable from OCaml and much of the functionality was not implemented > in the C API in LLVM 2.4. > >> SWIG (www.swig.org) recently added a C

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.