[llvm-dev] ORC JIT Weekly #1

Fri Jan 17 06:54:57 PST 2020

Hi Lang,

Great idea on the status updates, I'll be sure to check them out. Also 
thank you (and other contributors) for your work on ORC so far, it has 
been a fun API to tinker with and a great entry point into working with 
LLVM.

I'm for the most part just a lowly user of ORC but I try to contribute 
here and there when I can. Mostly by nagging about COFF support through 
bug reports ;-).

My use case for ORC is an expression-evaluator library I'm working on 
called JitCat (www.jitcat.org). It has some built-in reflection features 
to easily expose C++ functions/variables/classes for use in expressions. 
LLVM/ORC is used for code generation. Future plans are to extend JitCat 
into a fully featured scripting language. My own background is in game 
development, which is also what I use JitCat for myself.

Regards,

Machiel van Hooren
(jcmac on Discord)

On 17-Jan-20 03:00, Lang Hames via llvm-dev wrote:
> Hi All,
>
> In the interests of improving visibility into ORC JIT development I'm 
> going to try writing weekly status updates for the community. I hope 
> they will provide insight into the design and state of development of 
> LLVM's JIT APIs, as well as serving as a convenient space for 
> discussions among LLVM's large and growing community of JIT API users. 
> The
> length and detail will vary (depending on how much work I've gotten 
> through, and how long I can dedicate to writing the update), but if 
> people find the updates valuable I will make an effort to write at 
> least something. Questions and comments are most welcome (both on the 
> format, and on the content).
>
> Since this is the first update, I have also added some highlights from 
> last year, and the plan for 2020.
>
> /Highlights from 2019/:
>
> (1) ORCv1 was officially deprecated in LLVM 9. I have left it in for 
> the LLVM 10 branch, but plan to remove it from master in the coming 
> weeks. All development effort is now focused on ORCv2. If you are an 
> ORCv1 client, now's the time to switch over. If you need help please 
> ask on the llvm-dev mailing lists (make sure you CC me) or #llvm on 
> discord. There are also some tips available in 
> https://llvm.org/docs/ORCv2.html .
>
> (2) LLVM has a new JIT linker, JITLink, which is intended as an 
> eventual replacement for RuntimeDyld. The new design supports linker 
> plugins (allowing operation on the low-level bits generated by the JIT 
> linker) and native code models (RuntimeDyld required a custom code 
> model on some platforms). Currently JITLink only supports Darwin 
> x86-64 and arm64, but I hope to see support for new platforms added in 
> the future.
> (3) Google Summer of Code student Praveen Velliengiri demonstrated a 
> basic /speculative compilation/ system built on ORCv2. This system 
> analyses code added to the JIT and triggers early compilation on 
> background threads for code that is likely to be used at runtime. 
> Using this system Praveen was able to demonstrate significant speedups 
> on JIT execution of some SPEC benchmarks. He presented this work at 
> the 2019 LLVM Developer's Meeting in San Jose (see 
> https://preejackie.github.io/GSoC-2019-LLVM).
>
> /The plan for 2020/:
>
> - Improve JIT support for static initializers:
>   - Add support for running initializers from object files, which will 
> enable loading and caching of objects containing initializers.
>   - Improve support for platform-specific initializer kinds like 
> Objective-C +load methods.
>   - Switch from a push (“runConstructors”) to a pull model 
> (“getConstructorsToRun”) for initializer execution. This will allow 
> JIT’d code to “dlopen” other JIT’d code and run the initializers on 
> the expected thread, which is important for JIT’ing code that uses 
> threads and locks in initializers.
>
> - Improve adherence to static/dynamic linker rules: Weak symbol 
> resolution across JITDylib boundaries is still not handled correctly.
>
> - Remove ORCv1.
>
> - Bug fixes and documentation improvements.
>
> /Status report for this week/:
>
> -- I’ve been working on a generic implementation of the new 
> initialization APIs which I hope to be able to land next week. This 
> will replace the runConstructors/runDestructors API in LLJIT 
> (providing equivalent functionality: initializers will be discovered 
> by scanning llvm.global_ctors/llvm.global_dtors), and will enable the 
> development of platform specific initializer-support implementations.
>
> -- There’s a long-ish chat with @drmeister on the discord #llvm 
> channel about RuntimeDyld vs JITLink, and large vs small code model.
>
> -- I have added a new LLJIT example program that demonstrates how to 
> use lazy-reexports in ORCv2 to add lazy compilation: 
> llvm/examples/LLJITExamples/LLJITWithLazyReexports.
>
> -- COFF support in the JIT still lags ELF and MachO (See e.g. 
> http://llvm.org/PR40074 
> <https://bugs.llvm.org/show_bug.cgi?id=40074>). If there are any COFF 
> experts out there who are interested in helping out with JIT bugs 
> please let me know!
>
> Ok -- that’s enough from me for now. If you’re a JIT user, developer, 
> or just casual JIT-development observer (dblaikie), and you have 
> questions, comments, or just feel like introducing yourself: jump on 
> in. :)
>
> Lang.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200117/eeb9a473/attachment.html>