similar to: [LLVMdev] MCJIT and Lazy Compilation

Hi Andrew, I was about to write a belated reply to this message (sorry for the delay), but then I realized that pretty much everything useful that I have to say on the subject is contained in this message (which is in a thread Albert Graef already linked to): https://groups.google.com/d/msg/llvm-dev/Rk9cWdRX0Wg/Fa1Mn6cyS9UJ Generally, I do hope that MCJIT will be capable of replacing the old

Thanks for the update Andy. I'm very happy to be involved in anyway that is helpful. If you would like me to test ideas, or contribute to further discussions, then please let me know. I currently have extempore running nicely with MCJIT for the "monolithic" case and am working on various LLVM hacks to better understand the issues involved with non-monolithic approaches - in

OK, so I have some *preliminary* results, which are on the whole quite encouraging! I haven't had a great deal of time, but I have managed to get Extempore up and running with function (actually lexical closures so composed of quite a bit of additional guff) level compilation using Andy's multi module suggestion. I also have on-the-fly recompilation of existing closures working (caveats

Hi Andy and Andrew, I am very interested in this discussion as our co. have critical components that are dependent on the old JIT. We have implemented support for MCJIT mostly to get AVX support. The difference in module support is forcing us to duplicate a module when we want to JIT the same bitcode with different parameters. We also have code that depends on the JITEventListener API.

That's awesome! I think at this point having people try out various approaches and seeing what works and what doesn't is our biggest need in this area. Please do keep me informed about what you find out. -Andy From: Andrew Sorensen [mailto:digegoo at gmail.com] Sent: Wednesday, February 06, 2013 4:33 PM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJIT and Lazy

Hey Andy, Yep I've tested some non-trivial examples with loads of dependencies, both code and data, global, local and external symbol resolution etc.. Actually this was truly a piece of cake, nothing to do, the memory manager is working really nicely so far as I can tell. Relocations to sections are all working as expected (aside from previously mentioned ARM issue which is probably just

This is great news. Do you have any dependencies between your modules? For instance, one calling a function in another? If so, how did you handle that? Any chance you could share some code snippets or the relevant portions? -Andy From: Andrew Sorensen [mailto:digegoo at gmail.com] Sent: Thursday, February 14, 2013 11:48 PM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev]

Hi Andy/Albert, Sorry for the slow reply, my day job caught up with me. Two bits of progress. (a) MCJIT is working nicely for non-trivial examples in Extempore on x86 and ARM, and (b) the page permissions are now RO again. For your amusement a *very* cheesy video of Extempore running on-the-fly with MCJIT on an ARM Pandaboard. Viewer discretion is advised! https://vimeo.com/60407237 Here is the

I apologize to everyone for the tone of this email. I had a bad day yesterday. I'll start having a look at how I might be able to contribute to MCJIT. Cheers, Andrew. On Fri, Feb 1, 2013 at 1:55 PM, Andrew Sorensen <digegoo at gmail.com> wrote: > Does anyone have a roadmap for MCJIT with what I think people are > calling lazy compilation. > > Is this even on the cards?

On Fri, Feb 1, 2013 at 3:20 PM, Sean Silva <silvas at purdue.edu> wrote: > Eli, do you happen to know if we have a PR tracking this issue? (you > seem like you would be the person to know) I used to hack on MCJIT in the past while being at Intel. Since I moved to a different job I've been focusing on other parts of LLVM and haven't been really in touch with the MCJIT parts for

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi. I am a little unclear about the ARM JIT support status. Is it working as of LLVM 3.1? If not, is it on the roadmap for LLVM 3.2? I am not currently interested in NEON support so if thats unimplemented, thats fine. thanks, Rahul

Me again, this time not about patents but about wavelets. I've been doing some work on an image compression method which uses Haar wavelets plus VQ and entropy coding, and Segher Boessenkool told me in a private message that you are also doing a video codec. So I searched the archives and read a bunch of posts, but I never did find out any web address. And it's not on xiph.org either. So

Hi Rahul, I believe that ARM support is working in the MCJIT engine (as of llvm 3.1). If it wasn't working in the legacy JIT engine 10 months ago then it probably still isn't. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rahul Garg Sent: Tuesday, July 31, 2012 1:13 PM To: llvmdev at cs.uiuc.edu Subject: Re:

Hi All, I'm back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review! As described in my last email, this commit breaks the OrcJIT library

I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works correctly and the entry in the logfile is: Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from 192.38.97.131 port 2463 Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not accept the password any more and the entries in the logfile are: Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because

The only reference that I found so far here: http://llvm.org/devmtg/2011-09-16/EuroLLVM2011-LLVMplusARM.pdf The presenter states that the ARM JIT support is broken. But this is about 10 months old. Is the ARM JIT support still broken? Am I not looking at the right places in the documentation? Help will be appreciated. thanks, Rahul On Mon, Jul 30, 2012 at 4:53 AM, Rahul Garg <rahulgarg44 at

On Fri, Feb 1, 2013 at 3:05 PM, Andrew Sorensen <digegoo at gmail.com> wrote: > I apologize to everyone for the tone of this email. > I had a bad day yesterday. > > I'll start having a look at how I might be able to > contribute to MCJIT. > While you're waiting for others to reply, I would suggest to google this list's archives for MCJIT discussions. Just

Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > When writing a JIT compiler using LLVM, as I understand it, you can use two > alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would > it be accurate to say that if you want eager compilation - always compile > an entire module upfront - you should use MCJIT? +lang. My understanding is that

On 01/14/2015 02:33 PM, David Blaikie wrote: > > > On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com > <mailto:lhames at gmail.com>> wrote: > > Hi Dave, > > To confirm - I have no plans to remove MCJIT. I don't want > to change any behavior for existing clients. The new stuff > is opt-in. >