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 below) so from an end-user perspective this means that Extempore appears functionally equivalent with MCJIT and the old legacy JIT - hot-swapping audio signal processing code on-the-fly using MCJIT for example. Firstly multi-module definitely proved to be considerably easier than attempting to hack solutions for incremental *monolithic* module builds - which I also investigated. So the only major obstacle that I have run into so far are page permissions in relation to code relocations. I have a *safe* hack which is to toggle section permissions between rw and exec/ro in-between new object injections - however this is obviously problematic for code that is executing concurrently (i.e. secondary threads). I also have an *unsafe* hack, (purely for experimentation :-) whereby exec sections are left rw, and although very evil it works for test purposes (i.e. the audio example mentioned above). These solutions are obviously both inappropriate and I will investigate a *real* solution when I find some time. Also I didn't bother to implement section erasure, at the moment I'm just allocating new sections for each compile regardless of whether the new code replaces existing functionality. Having said that I don't see this as much of an issue, I was just to lazy to bother implementing it. I'll check this when I have some further free time. FYI this is all under x86. I did try to run under ARM but bombed out on an assertion error in the ARM ELF relocation code - specifically assert((*TargetPtr & 0x000F0FFF) == 0); I assume this is a result of something evil that I have done but I haven't yet had time to investigate any further. Again I'll let you know when I have some more time. Just a quick heads up but In general my initial thoughts are that MCJIT is really not that far off. Cheers, Andrew. On Fri, Feb 8, 2013 at 7:36 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:> 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 Compilation**** > > ** ** > > 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/20130215/9484f9ed/attachment.html>
Hi Andrew, This is very cool! Thanks for the update. -Jim On Feb 14, 2013, at 11:47 PM, Andrew Sorensen <digegoo at gmail.com> wrote:> 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 below) so from an end-user > perspective this means that Extempore appears functionally equivalent with MCJIT > and the old legacy JIT - hot-swapping audio signal processing code on-the-fly using > MCJIT for example. > > Firstly multi-module definitely proved to be considerably easier than attempting to hack > solutions for incremental *monolithic* module builds - which I also investigated. > > So the only major obstacle that I have run into so far are page permissions in relation > to code relocations. I have a *safe* hack which is to toggle section permissions between > rw and exec/ro in-between new object injections - however this is obviously problematic > for code that is executing concurrently (i.e. secondary threads). I also have an *unsafe* > hack, (purely for experimentation :-) whereby exec sections are left rw, and although > very evil it works for test purposes (i.e. the audio example mentioned above). These > solutions are obviously both inappropriate and I will investigate a *real* solution when > I find some time. > > Also I didn't bother to implement section erasure, at the moment I'm just allocating > new sections for each compile regardless of whether the new code replaces existing > functionality. Having said that I don't see this as much of an issue, I was just to > lazy to bother implementing it. I'll check this when I have some further free time. > > FYI this is all under x86. I did try to run under ARM but bombed out on an assertion error > in the ARM ELF relocation code - specifically assert((*TargetPtr & 0x000F0FFF) == 0); > I assume this is a result of something evil that I have done but I haven't yet had time to > investigate any further. Again I'll let you know when I have some more time. > > Just a quick heads up but In general my initial thoughts are that MCJIT is really not > that far off. > > Cheers, > Andrew. > > > > > > > > > > > > On Fri, Feb 8, 2013 at 7:36 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > 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 Compilation > > > > 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. > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130215/4d9261a8/attachment.html>
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] MCJIT and Lazy Compilation 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 below) so from an end-user perspective this means that Extempore appears functionally equivalent with MCJIT and the old legacy JIT - hot-swapping audio signal processing code on-the-fly using MCJIT for example. Firstly multi-module definitely proved to be considerably easier than attempting to hack solutions for incremental *monolithic* module builds - which I also investigated. So the only major obstacle that I have run into so far are page permissions in relation to code relocations. I have a *safe* hack which is to toggle section permissions between rw and exec/ro in-between new object injections - however this is obviously problematic for code that is executing concurrently (i.e. secondary threads). I also have an *unsafe* hack, (purely for experimentation :-) whereby exec sections are left rw, and although very evil it works for test purposes (i.e. the audio example mentioned above). These solutions are obviously both inappropriate and I will investigate a *real* solution when I find some time. Also I didn't bother to implement section erasure, at the moment I'm just allocating new sections for each compile regardless of whether the new code replaces existing functionality. Having said that I don't see this as much of an issue, I was just to lazy to bother implementing it. I'll check this when I have some further free time. FYI this is all under x86. I did try to run under ARM but bombed out on an assertion error in the ARM ELF relocation code - specifically assert((*TargetPtr & 0x000F0FFF) == 0); I assume this is a result of something evil that I have done but I haven't yet had time to investigate any further. Again I'll let you know when I have some more time. Just a quick heads up but In general my initial thoughts are that MCJIT is really not that far off. Cheers, Andrew. On Fri, Feb 8, 2013 at 7:36 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: 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<mailto:digegoo at gmail.com>] Sent: Wednesday, February 06, 2013 4:33 PM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] MCJIT and Lazy Compilation 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<mailto: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> [mailto: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<mailto: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/20130215/7b4d001c/attachment.html>
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 something that I'm doing wrong) with all global symbol relocs managed persistently by the MM between object injections. All in all it just works ;) I had to make a few minor adjustments to things like the LLParser for forward dependencies but overall really simple stuff. There certainly are some section management issues that will need to be addressed, but I don't see any major hurdles there. I was going to take a look into this next week? The biggest issue for multi-module is probably going to be client side not LLVM side, although this has not been a huge problem for me as most of this bookkeeping is already managed "client side" in extempore. I'm happy to send you code although it might be more useful for me to write a followup email outlining exactly what changes were made and then let the experts decide how best to proceed ;) Tomorrows a little hectic but I'll try to send a note through on Monday. Cheers, Andrew. On Sat, Feb 16, 2013 at 8:13 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:> 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] MCJIT and Lazy Compilation**** > > ** ** > > 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 below) so from an > end-user **** > > perspective this means that Extempore appears functionally equivalent with > MCJIT **** > > and the old legacy JIT - hot-swapping audio signal processing code > on-the-fly using **** > > MCJIT for example.**** > > ** ** > > Firstly multi-module definitely proved to be considerably easier than > attempting to hack**** > > solutions for incremental *monolithic* module builds - which I also > investigated.**** > > ** ** > > So the only major obstacle that I have run into so far are page > permissions in relation**** > > to code relocations. I have a *safe* hack which is to toggle section > permissions between**** > > rw and exec/ro in-between new object injections - however this is > obviously problematic **** > > for code that is executing concurrently (i.e. secondary threads). I also > have an *unsafe***** > > hack, (purely for experimentation :-) whereby exec sections are left rw, > and although **** > > very evil it works for test purposes (i.e. the audio example mentioned > above). These **** > > solutions are obviously both inappropriate and I will investigate a *real* > solution when **** > > I find some time.**** > > ** ** > > Also I didn't bother to implement section erasure, at the moment I'm just > allocating **** > > new sections for each compile regardless of whether the new code replaces > existing**** > > functionality. Having said that I don't see this as much of an issue, I > was just to**** > > lazy to bother implementing it. I'll check this when I have some further > free time.**** > > ** ** > > FYI this is all under x86. I did try to run under ARM but bombed out on > an assertion error **** > > in the ARM ELF relocation code - specifically assert((*TargetPtr & > 0x000F0FFF) == 0);**** > > I assume this is a result of something evil that I have done but I haven't > yet had time to **** > > investigate any further. Again I'll let you know when I have some more > time.**** > > ** ** > > Just a quick heads up but In general my initial thoughts are that MCJIT is > really not **** > > that far off.**** > > ** ** > > Cheers,**** > > Andrew.**** > > ** ** > > ** ** > > ** ** > > **** > > ** ** > > **** > > ** ** > > ** ** > > ** ** > > ** ** > > On Fri, Feb 8, 2013 at 7:36 AM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:**** > > 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 Compilation**** > > **** > > 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/20130216/789e2b63/attachment.html>
On 02/15/2013 11:13 PM, Kaylor, Andrew wrote:> 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?I'd like to see that, too. :) Andrew, great work, it's reassuring that someone finally takes the plunge and looks into this! -- 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