[llvm-dev] Improve JIT C API

Wed Oct 28 12:37:59 PDT 2015

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/b20adc29/attachment.html>