llvm dev - Nov 2012 - [LLVMdev] Old JIT Status (i.e., can we delete it?)

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?
> Albert

Cheers,
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.
> Eli
Cheers,
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.
> -Chris
Cheers,
Rafael