Does anyone have a roadmap for MCJIT with what I think people are calling lazy compilation. Is this even on the cards? I spent the last few hours moving my project (extempore.moso.com.au) over to MCJIT (particularly for ARM), and am a little horrified to discover no ability to compile, and just as importantly to recompile, at a function level. This is absolutely mandatory for my project. I have been looking enviously at MCJIT's ARM+DWARF support for a couple of years and was under the misapprehension that MCJIT was attempting to be a *drop-in* replacement for JIT. So I wasn't overly concerned about the primary JIT being largely neglected. This is obviously my fault, I wasn't paying close enough attention. I am now wondering what the LLVM project, in the large, plans regarding just-in-time compilation moving forward. Is MCJIT the future, and if so what kind of roadmap is there to replicate current JIT functionality. In my case in relation to function level (re)compilation. I appreciate everyones efforts, and that we all have our own agendas. I'm just trying to put my own roadmap in place. Cheers, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130201/0145c293/attachment.html>
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? > > I spent the last few hours moving my project (extempore.moso.com.au) > over to MCJIT (particularly for ARM), and am a little horrified to > discover > no ability to compile, and just as importantly to recompile, at a function > level. > This is absolutely mandatory for my project. > > I have been looking enviously at MCJIT's ARM+DWARF support for a > couple of years and was under the misapprehension that MCJIT was > attempting to be a *drop-in* replacement for JIT. So I wasn't overly > concerned about the primary JIT being largely neglected. This is obviously > my fault, I wasn't paying close enough attention. > > I am now wondering what the LLVM project, in the large, plans regarding > just-in-time compilation moving forward. Is MCJIT the future, and > if so what kind of roadmap is there to replicate current JIT > functionality. > In my case in relation to function level (re)compilation. > > I appreciate everyones efforts, and that we all have our own agendas. > I'm just trying to put my own roadmap in place. > > Cheers, > Andrew. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130202/b64fa75f/attachment.html>
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 within the past year there were many, including some which, IIRC, discussed exactly this issue of lazy compilation, dynamic function loading and so forth. Eli
On Fri, Feb 1, 2013 at 6: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.FWIW I didn't detect any bad tone when I read the email. You are certainly not the first to run into this issue and have similar assumptions about MCJIT (even just yesterday: see the thread "Stub function generation in MCJIT using lli"). And even before that this has come up numerous times.> I'll start having a look at how I might be able to > contribute to MCJIT.Awesome! Please don't hesitate to ask for help on the list; this is a recognized deficiency and there are certainly others that would greatly appreciate your work. -- Sean Silva
On 02/01/2013 04:55 AM, Andrew Sorensen wrote:> Does anyone have a roadmap for MCJIT with what I think people are > calling lazy compilation. > > Is this even on the cards?Well, this issue comes up on the ml every once in a while, here are two recent threads FYI: http://groups.google.com/group/llvm-dev/browse_thread/thread/464f5c59d457d168/85a4d042d45acdda?#85a4d042d45acdda http://groups.google.com/group/llvm-dev/browse_thread/thread/aee3a51120a97245/77c94d9c5df2572c I'm waiting for MCJIT to grow the dragon wings as well. :) I'm not into the MCJIT sources, but I'd be more than happy to help testing the lazy/incremental compilation stuff if you or someone else embarks on adding this to the MCJIT. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
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 JIT someday soon, though obviously it cannot do so until it provides equivalent functionality. I doubt it will ever be a "drop-in" replacement, but I hope that minimal rework will be needed. Most significantly, as can be seen in earlier discussions, things will need to be made Module-centric rather than Function-centric. It ought to be possible to write a utility class that takes a monolithic Module and breaks it up into sub-Modules for individual functions, but I think that would need to happen outside of the MCJIT engine because not all clients would want that kind of granularity. There's definitely a lot of work to be done here to get this right, and hopefully we'll get active participation in any design discussions to make sure the solution meets everyone's needs. I don't have a time table for this right now. I will file a Bugzilla report as soon as the LLVM server is ready. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew Sorensen Sent: Thursday, January 31, 2013 7:56 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] MCJIT and Lazy Compilation Does anyone have a roadmap for MCJIT with what I think people are calling lazy compilation. Is this even on the cards? I spent the last few hours moving my project (extempore.moso.com.au<http://extempore.moso.com.au>) over to MCJIT (particularly for ARM), and am a little horrified to discover no ability to compile, and just as importantly to recompile, at a function level. This is absolutely mandatory for my project. I have been looking enviously at MCJIT's ARM+DWARF support for a couple of years and was under the misapprehension that MCJIT was attempting to be a *drop-in* replacement for JIT. So I wasn't overly concerned about the primary JIT being largely neglected. This is obviously my fault, I wasn't paying close enough attention. I am now wondering what the LLVM project, in the large, plans regarding just-in-time compilation moving forward. Is MCJIT the future, and if so what kind of roadmap is there to replicate current JIT functionality. In my case in relation to function level (re)compilation. I appreciate everyones efforts, and that we all have our own agendas. I'm just trying to put my own roadmap in place. Cheers, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/4ed7e312/attachment.html>
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. Cheers. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Kaylor, Andrew [andrew.kaylor at intel.com] Sent: Tuesday, February 05, 2013 10:08 AM To: Andrew Sorensen; llvmdev at cs.uiuc.edu Subject: Re: [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 JIT someday soon, though obviously it cannot do so until it provides equivalent functionality. I doubt it will ever be a “drop-in” replacement, but I hope that minimal rework will be needed. Most significantly, as can be seen in earlier discussions, things will need to be made Module-centric rather than Function-centric. It ought to be possible to write a utility class that takes a monolithic Module and breaks it up into sub-Modules for individual functions, but I think that would need to happen outside of the MCJIT engine because not all clients would want that kind of granularity. There’s definitely a lot of work to be done here to get this right, and hopefully we’ll get active participation in any design discussions to make sure the solution meets everyone’s needs. I don’t have a time table for this right now. I will file a Bugzilla report as soon as the LLVM server is ready. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew Sorensen Sent: Thursday, January 31, 2013 7:56 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] MCJIT and Lazy Compilation Does anyone have a roadmap for MCJIT with what I think people are calling lazy compilation. Is this even on the cards? I spent the last few hours moving my project (extempore.moso.com.au<http://extempore.moso.com.au>) over to MCJIT (particularly for ARM), and am a little horrified to discover no ability to compile, and just as importantly to recompile, at a function level. This is absolutely mandatory for my project. I have been looking enviously at MCJIT's ARM+DWARF support for a couple of years and was under the misapprehension that MCJIT was attempting to be a *drop-in* replacement for JIT. So I wasn't overly concerned about the primary JIT being largely neglected. This is obviously my fault, I wasn't paying close enough attention. I am now wondering what the LLVM project, in the large, plans regarding just-in-time compilation moving forward. Is MCJIT the future, and if so what kind of roadmap is there to replicate current JIT functionality. In my case in relation to function level (re)compilation. I appreciate everyones efforts, and that we all have our own agendas. I'm just trying to put my own roadmap in place. Cheers, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130206/a94c05d2/attachment.html>
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 particular I'm starting with your multi-module approach. I will report back when (and if) I have something useful to contribute. Cheers, Andrew. On Wed, Feb 6, 2013 at 4:08 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:> 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 JIT > someday soon, though obviously it cannot do so until it provides equivalent > functionality. I doubt it will ever be a “drop-in” replacement, but I hope > that minimal rework will be needed. Most significantly, as can be seen in > earlier discussions, things will need to be made Module-centric rather than > Function-centric. It ought to be possible to write a utility class that > takes a monolithic Module and breaks it up into sub-Modules for individual > functions, but I think that would need to happen outside of the MCJIT > engine because not all clients would want that kind of granularity.**** > > ** ** > > There’s definitely a lot of work to be done here to get this right, and > hopefully we’ll get active participation in any design discussions to make > sure the solution meets everyone’s needs. I don’t have a time table for > this right now. I will file a Bugzilla report as soon as the LLVM server > is ready.**** > > ** ** > > -Andy**** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Andrew Sorensen > *Sent:* Thursday, January 31, 2013 7:56 PM > *To:* llvmdev at cs.uiuc.edu > *Subject:* [LLVMdev] MCJIT and Lazy Compilation**** > > ** ** > > Does anyone have a roadmap for MCJIT with what I think people are **** > > calling lazy compilation.**** > > ** ** > > Is this even on the cards?**** > > ** ** > > I spent the last few hours moving my project (extempore.moso.com.au) **** > > over to MCJIT (particularly for ARM), and am a little horrified to > discover **** > > no ability to compile, and just as importantly to recompile, at a function > level. **** > > This is absolutely mandatory for my project. **** > > ** ** > > I have been looking enviously at MCJIT's ARM+DWARF support for a **** > > couple of years and was under the misapprehension that MCJIT was **** > > attempting to be a *drop-in* replacement for JIT. So I wasn't overly**** > > concerned about the primary JIT being largely neglected. This is obviously > **** > > my fault, I wasn't paying close enough attention.**** > > ** ** > > I am now wondering what the LLVM project, in the large, plans regarding ** > ** > > just-in-time compilation moving forward. Is MCJIT the future, and**** > > if so what kind of roadmap is there to replicate current JIT > functionality. **** > > In my case in relation to function level (re)compilation.**** > > ** ** > > I appreciate everyones efforts, and that we all have our own agendas.**** > > I'm just trying to put my own roadmap in place.**** > > ** ** > > Cheers,**** > > Andrew.**** >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130207/d0451fb8/attachment.html>