similar to: [LLVMdev] Old JIT Status (i.e., can we delete it?)

On 11/24/2012 02:18 AM, Rafael Espíndola wrote: > Given that MCJIT is making good progress and that we just branched > 3.2, can we delete the old JIT or at least its EH support? The > attached patch removes just the EH bits. The "old" JIT is still in heavy use by 3rd party dynamic language projects, at least that's the case for my own (Pure). For these kinds of projects the

On 24.11.2012, at 02:18, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Writing some patches for MC I noticed that the old (non MC) JIT still > has a lot of duplicated code for producing EH frames which makes it a > bit harder to refactor code used by both implementations. > > Given that MCJIT is making good progress and that we just branched > 3.2, can we

> The "old" JIT is still in heavy use by 3rd party dynamic language > projects, at least that's the case for my own (Pure). For these kinds of > projects the facilities of the old JIT are an essential component of > LLVM; you need to be able to replace the definition of any function at > any time, having to recompile an entire module doesn't cut it. > >

On 11/24/2012 11:05 AM, Benjamin Kramer wrote: > The last major roadblock is lazy compilation. I don't think we can remove the old JIT until MCJIT supports that. I agree. But that alone may not be enough to support dynamic languages. In the Pure JIT I often need to be able to replace the IR of the body of an already lowered function and generate new code for it. This also needs to be fast,

So when you say 'lazy compilation' you mean 'deferred compilation of individual functions within a module until that function is needed,' right? That's certainly what 'lazy compilation' meant in the legacy JIT. I don't think that will ever be possible in MCJIT. If you look at the MCJIT engine you'll see that it delegates absolutely everything. In particular,

On 25.11.2012, at 00:34, Albert Graef <Dr.Graef at t-online.de> wrote: > On 11/24/2012 05:06 PM, Benjamin Kramer wrote: >> I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts for those backends. > > Why is this holding back MCJIT development? If the old JIT with the x86 >

On 11/25/2012 11:16 AM, Benjamin Kramer wrote: > It's possible to coexist, but increases the maintenance burden. Ok, I understand. > I can understand your concerns and I wouldn't have proposed this change if the old JIT for ARM and PPC actually worked. When running LLVM's regression tests on a ARM or PPC64 host most of the JIT tests simply fail. That's why the regression

On Nov 24, 2012, at 3:50 PM, Rafael Espíndola wrote: > On 24 November 2012 17:36, Chris Lattner <clattner at apple.com> wrote: >> As others have said, unfortunately it is premature to remove the old jit. I don't know of anyone using the EH code though... It can almost certainly be removed! > > Cool. I will remove the EH bits by the end of the week if no one complains.

On 24 November 2012 17:36, Chris Lattner <clattner at apple.com> wrote: > As others have said, unfortunately it is premature to remove the old jit. I don't know of anyone using the EH code though... It can almost certainly be removed! Cool. I will remove the EH bits by the end of the week if no one complains. > -Chris Cheers, Rafael

I don't think that GDB support is even present in the latest version of the old JIT in trunk. It used to have code to register emitted functions with GDB in a way that let GDB find the function name and EH frame information, but that got taken out back in January (r147615). As it stands now, I don't think GDB would provide any useful information at all about code emitted by the old JIT.

While the MCJIT doesn't cover all of the features the old JIT had, it has the huge advantage of actually producing working results on ARM and PPC64. The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even for simple examples. I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts

On 11/26/2012 10:35 PM, Kaylor, Andrew wrote: > So when you say 'lazy compilation' you mean 'deferred compilation of individual functions within a module until that function is needed,' right? That's certainly what 'lazy compilation' meant in the legacy JIT. Yes. Let's not forget what JIT actually means; this *is* what makes a compiler a JIT compiler. In Pure

On 11/24/2012 05:06 PM, Benjamin Kramer wrote: > I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts for those backends. Why is this holding back MCJIT development? If the old JIT with the x86 backend can coexist with MCJIT, why isn't this possible with the other backends? I have mixed

On Mon, Feb 3, 2014 at 11:55 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > This is a bug. The asm printer should be adding escapes so that you > would get a symbol named "$(foo)". What is the target triple? x86_64-unknown-linux-gnu I've attached a simple test case: source test.ll file and the .s output files produced with llc from LLVM 3.3 and 3.4,

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

On Fri, Nov 23, 2012 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Writing some patches for MC I noticed that the old (non MC) JIT still > has a lot of duplicated code for producing EH frames which makes it a > bit harder to refactor code used by both implementations. > > Given that MCJIT is making good progress and that we just branched > 3.2, can

As others have said, unfortunately it is premature to remove the old jit. I don't know of anyone using the EH code though... It can almost certainly be removed! -Chris On Nov 23, 2012, at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Writing some patches for MC I noticed that the old (non MC) JIT still > has a lot of duplicated code for producing EH frames

I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though. Another critical feature missing from MCJIT is the JITEventListener. This is usually for supporting debuggers and profiling tools. Ciao. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Albert

Sorry for speaking too soon. It is missing from 3.2 which is the version I have been using. If it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To: Manny Ko Cc: Albert Graef; Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT

I am somewhat surprised people are actually using TCO. I had to fixed a number of subtle bugs to get it working and even now I am not too happy with it. My focus was on finding non-ABI changing automatic tail call cases (aka gcc's sibcall). It's now done so I'll leave -tailcallopt alone for now. I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. Evan On Feb 5,