Hi, For a new language I am developing (in the very early stages, nothing public posted yet) I would like to able to use a JIT for several purposes: 1) Create a functional REPL as is done is done with in the Kaleidoscope tutorial. 2) Be able to interpret my language in addition to compiling. 3) While compiling, be able to execute arbitrary code at compile time. The simple case will be to get a value, similar to C++ constexpr but without any restrictions. The complicated case will be to support a full macro system similar to syntax-rules in Racket or defmacro in Lisp. For (1) I would require being able to execute a function at a time. I would also like to be able to discard temporary functions used just to get a value. For (2) and (3) lazy compilation is required, catching the results would also be great. For right now I plan to use a direct AST based interpreter, but I would also like have JIT available when it is needed. It looks like the new ORC JIT will be better suited for my needs. Would it be better to use the devel version of LLVM and the new JIT? Or is the new ORC JIT too much of a moving target and would it be better to stick with MCJIT? If it is best to stick with MCJIT can someone point me to a working Kaleidoscope that will work with MCJIT and the latest released version of LLVM. There are several versions floating around and I am confused on what version to use. The examples in Kaleidoscope/MCJIT/lazy don't compile with 3.6.1 and I was hoping there was a version that would compile. Let me know if anything is unclear. Thanks in Advance, Kevin
We (the LLILC project) have moved to ORC. It's been stable for us and much more flexible than MCJIT. (In terms of size of input, we've scaled up to being able to jit/run both the Roslyn C# compiler and 3k tests in the dotnet CoreCLR repo.) We don't have the same requirements as to compilation but ORC seems like it'd be a better fit. -R -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kevin Atkinson Sent: Wednesday, July 1, 2015 10:51 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] MCJIT or ORC JIT for new project? Hi, For a new language I am developing (in the very early stages, nothing public posted yet) I would like to able to use a JIT for several purposes: 1) Create a functional REPL as is done is done with in the Kaleidoscope tutorial. 2) Be able to interpret my language in addition to compiling. 3) While compiling, be able to execute arbitrary code at compile time. The simple case will be to get a value, similar to C++ constexpr but without any restrictions. The complicated case will be to support a full macro system similar to syntax-rules in Racket or defmacro in Lisp. For (1) I would require being able to execute a function at a time. I would also like to be able to discard temporary functions used just to get a value. For (2) and (3) lazy compilation is required, catching the results would also be great. For right now I plan to use a direct AST based interpreter, but I would also like have JIT available when it is needed. It looks like the new ORC JIT will be better suited for my needs. Would it be better to use the devel version of LLVM and the new JIT? Or is the new ORC JIT too much of a moving target and would it be better to stick with MCJIT? If it is best to stick with MCJIT can someone point me to a working Kaleidoscope that will work with MCJIT and the latest released version of LLVM. There are several versions floating around and I am confused on what version to use. The examples in Kaleidoscope/MCJIT/lazy don't compile with 3.6.1 and I was hoping there was a version that would compile. Let me know if anything is unclear. Thanks in Advance, Kevin _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Kevin, My recommendation for people starting new projects is to use ORC rather than MCJIT where possible, as ORC has a strict superset of MCJIT's functionality. There are no guarantees on ORC API stability however, so if that's truly critical then MCJIT's C API would be a better fit for you. If you're living on ToT (which we also generally recommend), then the minimal day-to-day churn on Orc should be manageable. If you're planning to live on stable releases you'll have the usual (and difficult-to-predict) inter-release headaches. Either way, let me know how your choice works out for you: I'm keen to keep improving LLVM's JIT support. Cheers, Lang. On Wed, Jul 1, 2015 at 10:50 PM, Kevin Atkinson <k at kevina.org> wrote:> > Hi, > > For a new language I am developing (in the very early stages, nothing > public posted yet) I would like to able to use a JIT for several purposes: > > 1) Create a functional REPL as is done is done with in the Kaleidoscope > tutorial. > > 2) Be able to interpret my language in addition to compiling. > > 3) While compiling, be able to execute arbitrary code at compile time. > The simple case will be to get a value, similar to C++ constexpr but > without any restrictions. The complicated case will be to support a full > macro system similar to syntax-rules in Racket or defmacro in Lisp. > > For (1) I would require being able to execute a function at a time. I > would also like to be able to discard temporary functions used just to get > a value. > > For (2) and (3) lazy compilation is required, catching the results would > also be great. > > For right now I plan to use a direct AST based interpreter, but I would > also like have JIT available when it is needed. > > It looks like the new ORC JIT will be better suited for my needs. Would > it be better to use the devel version of LLVM and the new JIT? Or is the > new ORC JIT too much of a moving target and would it be better to stick > with MCJIT? > > If it is best to stick with MCJIT can someone point me to a working > Kaleidoscope that will work with MCJIT and the latest released version of > LLVM. There are several versions floating around and I am confused on what > version to use. The examples in Kaleidoscope/MCJIT/lazy don't compile with > 3.6.1 and I was hoping there was a version that would compile. > > Let me know if anything is unclear. > > Thanks in Advance, > Kevin > > > _______________________________________________ > 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/20150703/835c0d8c/attachment.html>
Thanks for the advice. I think I will switch to the ToT[1] and try out the ORC JIT, I think I will switch to to a release version once 3.7 is out (assuming it included the ORC JIT.) I let you know how it goes. Kevin [1] which by the way I had to google as I never herd that term before :) On Fri, 3 Jul 2015, Lang Hames wrote:> Hi Kevin, > > My recommendation for people starting new projects is to use ORC rather > than MCJIT where possible, as ORC has a strict superset of MCJIT's > functionality. There are no guarantees on ORC API stability however, so if > that's truly critical then MCJIT's C API would be a better fit for you. > > If you're living on ToT (which we also generally recommend), then the > minimal day-to-day churn on Orc should be manageable. If you're planning to > live on stable releases you'll have the usual (and difficult-to-predict) > inter-release headaches. > > Either way, let me know how your choice works out for you: I'm keen to keep > improving LLVM's JIT support. > > Cheers, > Lang. > > > On Wed, Jul 1, 2015 at 10:50 PM, Kevin Atkinson <k at kevina.org> wrote: > >> >> Hi, >> >> For a new language I am developing (in the very early stages, nothing >> public posted yet) I would like to able to use a JIT for several purposes: >> >> 1) Create a functional REPL as is done is done with in the Kaleidoscope >> tutorial. >> >> 2) Be able to interpret my language in addition to compiling. >> >> 3) While compiling, be able to execute arbitrary code at compile time. >> The simple case will be to get a value, similar to C++ constexpr but >> without any restrictions. The complicated case will be to support a full >> macro system similar to syntax-rules in Racket or defmacro in Lisp. >> >> For (1) I would require being able to execute a function at a time. I >> would also like to be able to discard temporary functions used just to get >> a value. >> >> For (2) and (3) lazy compilation is required, catching the results would >> also be great. >> >> For right now I plan to use a direct AST based interpreter, but I would >> also like have JIT available when it is needed. >> >> It looks like the new ORC JIT will be better suited for my needs. Would >> it be better to use the devel version of LLVM and the new JIT? Or is the >> new ORC JIT too much of a moving target and would it be better to stick >> with MCJIT? >> >> If it is best to stick with MCJIT can someone point me to a working >> Kaleidoscope that will work with MCJIT and the latest released version of >> LLVM. There are several versions floating around and I am confused on what >> version to use. The examples in Kaleidoscope/MCJIT/lazy don't compile with >> 3.6.1 and I was hoping there was a version that would compile. >> >> Let me know if anything is unclear. >> >> Thanks in Advance, >> Kevin >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >