[llvm-dev] Improve JIT C API

[Lang Hames via llvm-dev]

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'll keep an eye on this thread tomorrow and see what other people have to
say as they get back from vacation, but I suspect the next step for the ORC
APIs will be to go in to llvm/include/llvm-c/unstable. They can live there
while they're under development and move to llvm-c if/when we're ready.

Cheers,
Lang.


On Mon, Sep 7, 2015 at 10:41 PM, James Y Knight <jyknight at google.com> wrote:

> On Sep 8, 2015, at 12:55 AM, Eric Christopher via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Mon, Sep 7, 2015 at 5:37 PM Lang Hames <lhames at gmail.com> wrote:
>
>> Hi Jauhien,
>>
>> A few people have requested a C API for ORC. I don't think ORC's ready
>> for a stable C API, but I'm not opposed to providing C bindings that will
>> probably be reasonably stable in practice (though with no guarantees). I've
>> actually already knocked up some trivial prototype bindings for Hayden
>> Livingston that could serve as a base (see attached).
>>
>> The next question is where unstable bindings should live. Juergen, Eric,
>> anyone else who wants to weigh in: I looked back over the C API thread, but
>> I don't think we settled on a home for this kind of thing. Any thoughts? I
>> could see either introducing a new include directory (something along the
>> lines of include/llvm/llvm-c-bindings) or a new c-bindings project on
>> llvm.org. The former would put all LLVM developers on the hook for
>> maintaining the bindings, the latter would leave maintenance to users of
>> the bindings project, and any volunteers. I prefer the second option: I
>> don't think core developers should be on the hook for maintaining unstable
>> bindings - that kind of special treatment should be reserved for the stable
>> API.
>>
>>
> We hadn't figured out a location. I was the one that wanted to move stable
> to a new directory and Jim wanted to move unstable. I think either will
> work ultimately, just a matter of personal preference in the "when do we
> count restart".
>
> That said, as long as you put a comment at the top saying that the ORC
> bindings are unstable and put them in a new file I'm not opposed to just
> putting them in llvm-c for now. I also don't think I'm going to win the
> argument of "stable moves" so if you'd like to make a new unstable
> directory I'm perfectly happy with that direction too.
>
> Thoughts?
>
>
> +1 to putting it in llvm-c for now (but also for good).
>
> I really think the existing LLVM-C APIs should all be considered
> "reasonably stable in practice", not "absolutely 100% stable forever".
> "Reasonably stable in practice" means to me: if you need to remove a
> function, then, ok, do that. But make a reasonable effort to avoid doing so
> first, for users' sake. And don't change the ABI of existing functions.
>
> And thus, if ORC is at that level (probably is?), I think it should just
> go in there with all the rest of them.
>
> BTW, have a patch: http://reviews.llvm.org/D12685 saying that in more
> words.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150907/8e8dff99/attachment.html>