[llvm-dev] ORC JIT Weekly #1
Praveen Velliengiri via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 22 06:31:43 PST 2020
Didn't see this one coming. This is great and very helpful to keep track of
latest development in ORC!!
On Wed, 22 Jan 2020 at 04:57, Christian Schafmeister via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I appreciate the weekly updates very much - thanks Lang!
> Everything I know about the ORCV2 JIT I learned from Lang's 2018 LLVM-Dev
> There is sample code scattered throughout the talk that I've watched over
> and over again to piece together our JIT.
> On Tue, Jan 21, 2020 at 4:16 PM Lang Hames <lhames at gmail.com> wrote:
>> Hi All,
>> Ok -- sounds like there's enough interest to keep going with these status
>> updates. You can expect update #2 in a couple of days. :)
>> Nice idea! - might even be worth spinning up a separate channel on the
>>> Discord for the JIT?
>> Seems reasonable to me. There has been a lot of JIT discussion in #llvm
>> -- it might be nice to move it to a #jit channel to maximize the
>> signal-to-noise ratio.
>> My use case for ORC is an expression-evaluator library I'm working on
>>> called JitCat (www.jitcat.org)...
>> Sounds very cool!
>> 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 ;-).
>> Anything you can contribute (bug reports included) is very welcome.
>> Debugging and development for Windows is *extra* welcome, since I don't
>> have a windows box to develop or test with.
>> One thing that will be useful (and was done to some extent with ORCv1) is
>>> to expose ORCv2's API via C-compatible bindings such that code from
>>> languages other than C++ (Rust for me) can effectively use it, including
>>> things such as the equivalent of -march=native and introspection such that
>>> the supported SIMD widths can be detected. I'm planning on using ORC to
>>> compile shaders for Kazan, the GPU driver that I'm writing for
>>> libre-riscv's hybrid cpu/gpu.
>> That's a really good point. And timely: We need an ORCv2 C API before we
>> can kill off ORCv1. We should use http://llvm.org/PR31103 to track this
>> (hopefully we can finally close it). If you're interested in this work
>> please CC yourself on that bug.
>> There are two approaches we can take to C bindings for ORCv2. The first
>> one I'll call "wrap LLJIT", and it's pretty much what it sounds like: We
>> provide an API for initializing an LLJITBuilder, and accessing methods in
>> the resulting LLJIT object. This would provide a similar level of
>> functionality to the ExecutionEngine bindings, and also enable basic lazy
>> compilation. The second approach would be to wrap the lower level APIs
>> (ExecutionSession, MaterializationUnit, etc.) to allow clients to build
>> their own JIT instances in C. These approaches aren't mutually exclusive,
>> and the best way forward is probably to start with the first approach, then
>> add elements from the second over time.
>> Any volunteers to work on this? I need to finish the new initializer work
>> before I can tackle this, so I might be a while yet.
>> As a starter using LLVM JIT to improve OLAP execution engine performance,
>>> I'm very glad to hear that. I can't find some useful document help me get
>>> start to use the new ORC JIT API quickly. Only can find some examples how
>>> to use it, but don't know the internal from low level, and very blurred to
>>> design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT
>>> more easy to adoption.
>> Ok. Which tutorials have you been following? If possible, could you write
>> some notes on where you got stuck, or where the design was difficult to
>> follow? That will help us determine where the documentation and tutorials
>> could most benefit from improvement.
>> -- Lang.
>> On Fri, Jan 17, 2020 at 11:35 PM guangnan he <gnhe2009 at gmail.com> wrote:
>>> Hi, Lang
>>> As a starter using LLVM JIT to improve OLAP execution engine
>>> performance, I'm very glad to hear that. I can't find some useful document
>>> help me get start to use the new ORC JIT API quickly. Only can find some
>>> examples how to use it, but don't know the internal from low level, and
>>> very blurred to design a clearly JIT toolset. Hope more tutorials add in
>>> and help ORC JIT more easy to adoption.
>>> Big thanks.
>>> Jacob Lifshay via llvm-dev <llvm-dev at lists.llvm.org> 于2020年1月17日周五
>>>> Thank you for creating weekly updates, they will be quite useful, since
>>>> previously ORC development seemed rather opaque.
>>>> One thing that will be useful (and was done to some extent with ORCv1)
>>>> is to expose ORCv2's API via C-compatible bindings such that code from
>>>> languages other than C++ (Rust for me) can effectively use it, including
>>>> things such as the equivalent of -march=native and introspection such that
>>>> the supported SIMD widths can be detected. I'm planning on using ORC to
>>>> compile shaders for Kazan, the GPU driver that I'm writing for
>>>> libre-riscv's hybrid cpu/gpu.
>>>> Jacob Lifshay
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>> Guang-Nan He
> Christian Schafmeister
> Professor, Chemistry Department
> Temple University
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev