[llvm-dev] Orc JIT v1 Deprecation

[Lang Hames via llvm-dev]

Hi Alex,

I'll try to migrate my code to the v2 API and describe the process, but
> please don't take my words as a promise :-D


No worries. Any help will be greatly appreciated!

After re-reading my statement I realized that it was too harsh, sorry about
> that. I rather meant that I was only able to get information post factum,
> which reminded some of our hardware vendors :)


 No worries. Getting concurrency into ORC (which is the main aim of ORCv2,
vs ORCv1) has involved a lot of trial and error, and corresponding churn in
the APIs, and that has made documentation challenging. This isn't intended
to be a permanent state of affairs though, and the more the APIs settle
down, the easier and more rewarding documentation will be (both to write
and to use).

> I plan to add deprecation attributes to the legacy classes on trunk so
> that clients who use 9.0 receive warnings.
> That's a very good idea. I think I understand your motivation to force
> everyone to use the new APIs, but I also think it makes sense to make the
> migration process a bit more smooth.


I have filed http://llvm.org/PR41986 if anyone wants to jump on it. :)

-- Lang.

On Tue, May 21, 2019 at 12:51 AM Alex Denisov <1101.debian at gmail.com> wrote:

> Hello everyone,
>
> Praveen,
>
> > You can also take a look at "Updating ORC for Concurrency" talk by lang
> hames, the talk explains about the new APIs.
>
> It's a good reference, but it is not sufficient as communication channel,
> imho.
>
> > For documentation kaleidoscope, I don't think the updated version is
> available yet.
>
> It is very often outdated, so I developed (not on purpose) a mental model
> of not relying on it.
>
> Lang,
>
> > There is no guide yet. It sounds like there is plenty of interest in
> creating one. I’m also going to try to post a draft of the ORCv2 design
> document we discussed later tonight.
>
> I'll try to migrate my code to the v2 API and describe the process, but
> please don't take my words as a promise :-D
>
> > It is definitely not closed source.
>
> After re-reading my statement I realized that it was too harsh, sorry
> about that. I rather meant that I was only able to get information post
> factum, which reminded some of our hardware vendors :)
>
> > I plan to add deprecation attributes to the legacy classes on trunk so
> that clients who use 9.0 receive warnings.
>
> That's a very good idea. I think I understand your motivation to force
> everyone to use the new APIs, but I also think it makes sense to make the
> migration process a bit more smooth.
>
>
> Stefan,
>
> Thanks for the summary and for bringing more people into the discussion.
>
> Thanks a lot for your contributions, folks!
>
> Cheers,
> Alex.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190522/901db2d9/attachment.html>