[llvm-dev] ORC JIT Weekly #1

Tue Jan 21 13:16:43 PST 2020

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/dc0a3f3f/attachment.html>