similar to: [LLVMdev] Ahoy JIT Users

[Resend: I don't know why Reply-to-all button comes after Repy one] On Sat, Nov 13, 2010 at 1:42 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi, > > I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. > > If you are a "sophisticated" JIT user and are using either internal > APIs (either by integrating with LLVM, or by other C++

Will this poking include converting the JIT to use the MC framework? I've added an MC based asm parser, disassembler, and code emitter recently to the MBlaze backend and it would be nice to get JIT support automatically :) -- Wesley Peck On Nov 12, 2010, at 7:42 PM, Daniel Dunbar wrote: > Hi, > > I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. >

On Fri, Nov 12, 2010 at 6:01 PM, Wesley Peck <peckw at wesleypeck.com> wrote: > Will this poking include converting the JIT to use the MC framework? That is the motivation for me poking at things, yes. > I've added an MC based asm parser, disassembler, and code emitter recently to the MBlaze backend and it would be nice to get JIT support automatically :) I agree, that would be

On Fri, 12 Nov 2010 17:42:57, Daniel Dunbar <daniel at zuster.org> wrote: > If you are a "sophisticated" JIT user and are using either internal > APIs (either by integrating with LLVM, or by other C++ tricks), or are > using obscure or poorly documented public APIs (e.g., why is > runJITOnFunction exposed?) please make me aware of it! Hi, Daniel! We

Thanks Reid - I'm on Windows. I guess I just assumed I was missing something obvious in how to hook up the JIT and disassembler! Given the nice looking disassembly code I found, I thought people would be doing it all the time :-) b. On Tue, Jul 6, 2010 at 8:41 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > If you're on a recent flavor of Linux, you may be able to just

----- "Evan Cheng" <evan.cheng at apple.com> wrote: > On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > > > Evan, > > So, if I understand you correctly, the design you have in mind is > > to: create a PassManager, pass it to the JIT on construction, and > > modify runJITOnFunction to run the second PassManager on the > > Function

Hello, JIT::recompileAndRelinkFunction's runJITOnFunction does not use the MCI arg, causing null pointer deferences at every call. Attached patch makes runJITOnFunction more reliable. Thanks, Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspire confidence at all. Later I learned that I had been introduced to electronic engineers.

Hi Bill, I'm coincidently planning right now on doing exactly the same things as you. I haven't yet had a chance to implement the code, but I can point you to how I currently believe you can get access to what you need. If you take a look at the code for the implementation of lvm::JIT::runJITOnFunction(Function *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is

Hi all, As promised, here is the rough design of the upcoming MC-JIT*. Feedback appreciated! (*) To be clear, we are only calling it the MC-JIT until we have finished killing the old one. When I say JIT below, I mean the MC-JIT. I basically am ignoring completely the existing JIT. I will keep things API compatible whenever possible, of course. I see two main design directions for the JIT: --

On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: > On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: >> Attached patch makes runJITOnFunction more reliable. > > When would MCI be null? Everytime you call recompileAndRelinkFunction. It calls runJITOnFunction without specifying the MCI argument, which get defaulted to NULL. Gianluca -- It was a

Quick follow up here: I talked to Eric for a bit about this proposal, and he convinced me that we should take a slightly different tack. I'll write a bit more about it later. The idea Eric convinced me was better is to not invent a FOO format, but just use the native platform object format and focus on writing essentially a runtime linker for that platforms object files. This has various

Thanks for all the hints everyone. Based on your suggestion, O.J., I've added code to toy.cpp from the tutorial to disassemble. ready> 1+1; ready> movabsq $140737353367568, %rax movsd (%rax), %xmm0 ret Evaluated to 2.000000 ready> Which looks correct by inspection - printing the byte array to stdout and feeding it to llvm-mc offline produces the same code as one would also

What kind of restrictions will the existing object file formats impose on the JIT? I don't know enough about the JIT and object file format interaction to know if this will be an issue. It seems clear that it would be worse to try to encode "extra things" in some obscure way than to create the FOO format initially. If FOO is truly a superset of everything this could even be the

Hi I hope this is a proper place to put my question. I've compiled Kaleidoscope from "Adding JIT and Optimizer Support" tutorial. Basically it works just fine but when I try to run extern'ed putchard function it aborts. Please, tell me what am I doing wrong? Here is more information: My PC runs FreeBSD. I've copied the toy source code exactly and didn't change it.

Hello all, I've already bothered people on IRC with this question and it was recommended to ask it here. First of all, some context. In Rubinius (http://rubini.us/, http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create LLVM IR using the C++ API and turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the

Hi, I was just reading through the Kaleidoscope tutorial (which is greatly written and understandable, thanks! ) hoping to get some glimpse about the workings of the JIT and the optimizations that are done at run time. I am curious as to how LLVM's JIT dynamically generates native code from bit code at run time and runs that code (I think my question is also somewhat more general in the sense

Evan, So, if I understand you correctly, the design you have in mind is to: create a PassManager, pass it to the JIT on construction, and modify runJITOnFunction to run the second PassManager on the Function being jit'd before running the codegen PassManager. Thanks. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing

On Mon, 15 Nov 2010 11:34:22 -0800 Daniel Dunbar <daniel at zuster.org> wrote: > Quick follow up here: > > I talked to Eric for a bit about this proposal, and he convinced me > that we should take a slightly different tack. I'll write a bit more > about it later. > > The idea Eric convinced me was better is to not invent a FOO format, > but just use the native

Hi, I use JIT to execute the following LLVM IR, ------------------------------------------------------------------------------------------------------------ define internal fastcc i32 @L_00008120_(%struct.ThreadContext* %ThreadCtx) { L_00000000_: %0 = alloca i32 %1 = alloca i32 %2 = alloca %struct.ThreadContext*, align 4 store %struct.ThreadContext* %ThreadCtx, %struct.ThreadContext**

On Thu, Jun 18, 2009 at 3:57 PM, Jules Jacobs<julesjacobs at gmail.com> wrote: > How can I call C++ libraries (LLVM & Qt for example) from a language that's > implemented on top of LLVM? You can call them the same way a C++ file compiled with llvm-g++ would call them. Essentially, it's complicated enough that you probably don't want to do it for any interface of