[llvm-dev] Improve JIT C API

[Eric Christopher via llvm-dev]

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/20151017/759d6ce7/attachment.html>