search for: czoccolo

Displaying 14 results from an estimated 14 matches for "czoccolo".

Did you mean: zoccolo
2009 Feb 16
4
[LLVMdev] LLVM C bindings
...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 --------------------------------------------------------------------------
2009 Feb 25
0
[LLVMdev] Problem running JITted functions from x86_64 inside a dynamic library?
...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 --------------------------------------------------------------------------
2009 Mar 30
2
[LLVMdev] Bug in X86CompilationCallback_SSE
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
2009 Mar 30
0
[LLVMdev] Bug in X86CompilationCallback_SSE
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
2009 Mar 12
0
[LLVMdev] Bug in X86CompilationCallback_SSE
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
2009 Apr 30
0
[LLVMdev] Stack alignment in JIT compiled code
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
2009 May 01
3
[LLVMdev] Stack alignment in JIT compiled code
...________ > 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 --------------------------------------------------------------------------
2009 Mar 10
2
[LLVMdev] Bug in X86CompilationCallback_SSE
...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 --------------------------------------------------------------------------
2009 Apr 30
3
[LLVMdev] Stack alignment in JIT compiled code
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
2009 Mar 11
4
[LLVMdev] Bug in X86CompilationCallback_SSE
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
2009 Mar 12
2
[LLVMdev] Bug in X86CompilationCallback_SSE
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
2009 Mar 20
0
[LLVMdev] Bug in X86CompilationCallback_SSE
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
2009 Feb 18
1
[LLVMdev] LLVM C bindings
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
2009 Feb 26
1
[LLVMdev] Problem with x86_64 JIT from a .so on Linux (LLVM 2.4)
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.