[llvm-dev] ORC JIT Weekly #1

Tue Jan 21 15:27:00 PST 2020

I appreciate the weekly updates very much - thanks Lang!

Everything I know about the ORCV2 JIT I learned from Lang's 2018 LLVM-Dev
talk.
There is sample code scattered throughout the talk that I've watched over
and over again to piece together our JIT.

There

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日周五
>> 下午11:38写道：
>>
>>> 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
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
>> --
>> Guang-Nan He
>>
>>

-- 
Christian Schafmeister
Professor, Chemistry Department
Temple University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/112d54b6/attachment.html>