[llvm-dev] Improve JIT C API

[Lang Hames via llvm-dev]

So "over the weekend" ended up being slightly optimistic, but the initial
Orc C APIs are now in tree, just in time for the dev meeting.

You'll find the header in "llvm/include/llvm-c/OrcBindings.h", and some
test code in "unittests/ExecutionEngine/Orc/OrcCAPITest.cpp".

There are a lot of things missing in this initial checkin. The big ones
that I'm aware of are:

1) Direct access to the compile callbacks API.
2) Support for custom memory managers.
3) Customization of the optimization pipeline.

If you've got other features that you'd like to see added please file
feature requests on llvm.org/bugs.

I'll be working on these features as time allows, but I'm pretty busy with
other projects at the moment. If anyone else wants to take a shot, patches
are very welcome too.

- Lang.

On Fri, Oct 16, 2015 at 8:59 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Eric,
>
> > I think some people are waiting until the conference to sit down and
> discuss. At this point it's probably fine to wait.
>
> That makes sense.
>
> > *shrug* For now I'm ok with just llvm-c with a comment of "these apis
> are guaranteed to change use at your own risk", or some similar idea.
>
> Sounds good. I'll commit something like this over the weekend. I'd like to
> give people a chance to play with it before the conference so they can form
> initial impressions.
>
> Cheers,
> Lang.
>
> On Fri, Oct 16, 2015 at 5:35 PM, Eric Christopher <echristo at gmail.com>
> wrote:
>
>>
>>
>> On Fri, Oct 16, 2015 at 5:19 PM Lang Hames <lhames at gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> Belatedly circling back to this, with apologies for not being able to
>>> keep up at the time.
>>>
>>> I expect the ORC C APIs to take at least a couple of release cycles to
>>> get ironed out to the point where they could be considered stable. It would
>>> be wonderful if it happened more quickly, and maybe we'll get lucky, but
>>> I'm not counting on it. :)
>>>
>>> That said - the best way to get things moving is to have people use them
>>> and discover where the issues are. So with that in mind: Did we read a
>>> consensus on a reasonable staging area?
>>>
>>>
>> Nope :) I think some people are waiting until the conference to sit down
>> and discuss. At this point it's probably fine to wait.
>>
>>
>>> Would it be reasonable to put the prototype APIs in
>>> "include/llvm-c-unstable"?
>>>
>>>
>> *shrug* For now I'm ok with just llvm-c with a comment of "these apis are
>> guaranteed to change use at your own risk", or some similar idea.
>>
>> -eric
>>
>>
>>> Cheers,
>>> Lang.
>>>
>>>
>>> On Tue, Sep 8, 2015 at 9:11 AM, James Y Knight <jyknight at google.com>
>>> wrote:
>>>
>>>> On Sep 8, 2015, at 2:07 AM, Lang Hames <lhames at gmail.com> wrote:
>>>> > Hi James,
>>>> >
>>>> > > And thus, if ORC is at that level (probably is?), I think it should
>>>> just go in there with all the rest of them.
>>>> >
>>>> > ORC is definitely not at that level yet - the attached patch was for
>>>> a prototype of the APIs and lacks many features. If it goes in, I expect it
>>>> to change reasonably quickly over the next few weeks/months as features are
>>>> added and bugs uncovered and fixed. After that I would expect it to calm
>>>> down a bit, but it'll be a while before it could approach the kind of
>>>> stability described in the document you posted for review.
>>>>
>>>> I had actually meant the underlying system, not the LLVM-C wrapper
>>>> itself.
>>>>
>>>> But, that's actually a good point which is not addressed by the draft
>>>> policy: *when* do stability rules kick in? Instantaneously? A couple weeks
>>>> of "oops" buffer time? The next release? Clearly, while a complex addition
>>>> to the LLVM-C wrapper API is under development, its interface really cannot
>>>> possibly be stable yet -- no matter what the underlying API's stability is,
>>>> or what the intended stability is.
>>>>
>>>> Saying that a stability policy doesn't apply until the next llvm
>>>> release is attractive (and, is what the policy for IR changes says about IR
>>>> compatibility). But my understanding is that a lot of people using llvm
>>>> just work off of llvm trunk (and even make release branches from arbitrary
>>>> points between releases), so that may not be the best policy?
>>>>
>>>> Having the "unstable" directory be where under-active-development C API
>>>> wrappers go while under development, and then graduating out when they're
>>>> "done" makes some sense. That is: "unstable" should not be considered a
>>>> final resting place for "unstable" APIs -- it's just for complex additions
>>>> to the wrappers that are currently under development.
>>>>
>>>> I'm a bit wary, because it seems like it could still end up a place
>>>> where people will add stuff (better safe than sorry, so put it in
>>>> unstable!), and then it will just get left there and never moved out,
>>>> because that would take energy, and people are busy, and forget. So then
>>>> you end up with a random subset of the API sitting in "unstable", despite
>>>> being essentially unchanged for the last year or five. And of course other
>>>> projects will have grown to depend on it by then, too.
>>>>
>>>> Perhaps if the "install" build target excluded installing the headers
>>>> from "unstable", too; that'd at least be a bit of incentive to move them
>>>> out when they're ready, since it'll be annoying that they're not available
>>>> in installed headers.
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151028/a333814e/attachment.html>