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 delete the old JIT or at least its EH support? The attached patch removes just the EH bits. Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: t.patch Type: application/octet-stream Size: 27116 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121123/097ea8d3/attachment.obj>
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 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. I'd really like to give MCJIT a whirl and see whether I could use it for Pure, but apart from some past developer meeting slides there hasn't been a progress report on MCJIT in a while, and the available blog posts are from 2010. Is MCJIT working on Windows yet? PPC? ARM? Does it support lazy compilation now? Module linkage? Is there documentation on how to migrate from the "old" JIT somewhere? 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
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 delete the old JIT or at least its EH support? The > attached patch removes just the EH bits.The last major roadblock is lazy compilation. I don't think we can remove the old JIT until MCJIT supports that. - Ben
> 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. > > I'd really like to give MCJIT a whirl and see whether I could use it for > Pure, but apart from some past developer meeting slides there hasn't > been a progress report on MCJIT in a while, and the available blog posts > are from 2010. Is MCJIT working on Windows yet? PPC? ARM? Does it > support lazy compilation now? Module linkage? Is there documentation on > how to migrate from the "old" JIT somewhere?I think ARM and PPC64 work. Windows work (using ELF in memory). As Benjamin points out lazy compilation is missing. Do you need the EH bits I remove in the patch in the original message?> AlbertCheers, Rafael
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 we delete the old JIT or at least its EH support? The > attached patch removes just the EH bits. >Rafael, could you mention in a few words the role these "EH bits" serve for the legacy JIT? What is the meaning/impact of removing them? - i.e. what will stop working? Given that there's still need of the legacy JIT to be around, what is the advantage of removing this code, at the expense of losing existing functionality? Eli
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 recompiling the entire module when this happens is not an option. Will this be possible with MCJIT? -- 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
Albert Graef <Dr.Graef at t-online.de> writes:> 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.What Albert said. As a more specific note, I have no problem with removing the EH support, but the "old" JIT should stay until MCJIT is on par with it. And now that we are talking about the JITs, is the MCJIT faster than the "old" JIT at generating code with the same optimization level? On medium-sized modules (hundreds of KB of native code)?
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 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 delete the old JIT or at least its EH support? The > attached patch removes just the EH bits. > > Cheers, > Rafael > <t.patch> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> Rafael, could you mention in a few words the role these "EH bits" > serve for the legacy JIT? What is the meaning/impact of removing them? > - i.e. what will stop working? Given that there's still need of the > legacy JIT to be around, what is the advantage of removing this code, > at the expense of losing existing functionality?I have never used them myself, so I can talk about what they do, not what they are used for. They produce exception handling tables that look similar to (are?) the ones specified by the x86_64 abi. This tables are used by stack unwinders and could probably be used to JIT code that uses "zero cost" exceptions.> EliCheers, Rafael
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.> -ChrisCheers, Rafael