search for: digegoo

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 litt...

...allocation. Andy, aside from these 4 points does everything here sound OK to you, and if so how would you like to proceed. I can put *some* time in but you'll need to give me some direction about what you would like done. Cheers, Andrew. On Sat, Feb 16, 2013 at 5:26 PM, Andrew Sorensen <digegoo at gmail.com> wrote: > 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 workin...

...ules? 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 > encoura...

...t; 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 invol...

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 t...

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

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 f...

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 a...

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

Hi, I have a question regarding the LLParser and the new type system rewrite when running the JIT. I think there may be a problem with the parser not picking up on named types currently defined in a given Module (global context). However, I don't have much experience with the LLVM internals so there's a good chance that I'm not fully understanding the new changes ;) For Example:

Hey Sean, I'm sure Andy.K will have some thoughts on this but I don't imagine any major API changes being required. The changes that I have been making are really very minor, all the work is already done. However I can imagine some client side fallout due to the multi-module nature of the proposed solution. The client side problem being that I imagine that many people are using a single