[llvm-dev] Improve JIT C API

Wed Oct 28 12:42:09 PDT 2015

My understanding is that there is a BoF at the dev meeting where C API
policy will be discussed.

I noted in the header file, but forgot to explicitly mention in my email:
This new API is entirely experimental, and non-stable. It's only going out
so that people have a chance to experiment with it. I expect it to change
to accommodate whatever policy is decided at or after the dev meeting.

Cheers,
Lang.

On Wed, Oct 28, 2015 at 12:37 PM, deadal nix <deadalnix at gmail.com> wrote:

> Note that I'm unhappy with getting the C API improved - inf act I'm all
> for it -, but my understanding that thing were stale on that side while the
> policy is decided. Could you guys chime in there before pushing a ton of
> new things in the API ?
>
> 2015-10-28 10:51 GMT-07:00 Lang Hames via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> 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.
>>>>>>
>>>>>>
>>>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://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/20151028/5757f10b/attachment.html>