[llvm-dev] ORC JIT Weekly #21 -- OrcV1 removal, Removable code, and Remote TargetProcessControl

[Lang Hames via llvm-dev]

Hi Fāng-ruì,

In LLVM 12.0 ORCv1 will be removed entirely? :)


Better late than never, right? ;)

It turns out several clients were relying on the OrcV1 removable code
feature and I didn't want to force them onto OrcV2 without a solution for
that. So far I'm happy with how the OrcV2 removable code prototype is
shaping up -- assuming we don't discover any major issues with the idea I
do hope to remove OrcV1 before LLVM 12 is released.

-- Lang.

On Mon, Sep 14, 2020 at 10:41 AM Fāng-ruì Sòng <maskray at google.com> wrote:

> On https://llvm.org/docs/ORCv2.html#transitioning-from-orcv1-to-orcv2
>
> > "The majority of the ORCv1 layers and utilities were renamed with a
> ‘Legacy’ prefix in LLVM 8.0, and have deprecation warnings attached in LLVM
> 9.0. In LLVM 10.0 ORCv1 will be removed entirely.
>
> In LLVM 12.0 ORCv1 will be removed entirely? :)   (Noticed while
> looking at https://github.com/ClickHouse/ClickHouse/issues/13281 )
>
> On Mon, Sep 14, 2020 at 10:26 AM Lang Hames via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Oh, I almost forgot: The "orcv1-removal-with-remote-tpc" also contains a
> next step towards breaking Orc up into distinct libraries.
> >
> > Chris Bieneman started this process on the mainline a while back by
> moving some of the Orc error types into a separate OrcError library (Thanks
> Chris!). The orcv1-removal-with-remote-tpc branch takes this further.
> >
> > (1) It adds a new OrcTargetProcess library that contains code specific
> to JIT execution. E.g. runAsMain, in-process eh-frame registration code,
> and the OrcRPCTPCServer type.
> > (2) It renames OrcError to OrcShared. This will be a home for types that
> are shared between Orc and OrcTargetProcess. It's likely to me mostly
> headers, but may contain some code snippets.
> >
> > This break-up isn't fully implemented in the branch yet: Orc still
> depends directly on OrcTargetProcess in places. This is just incomplete
> work, not by design.
> >
> > Eventually I hope to decouple Orc (and JITLink) from ExecutionEngine
> entirely. With the removal of OrcV1 this should be much easier: The main
> changes will be a substitute types for JITTargetAddress and
> JITEvaluatedSymbol (we can come up with better names for them while we're
> at it), and moving RTDyldObjectLinkingLayer from ORC to RuntimeDyld.
> >
> > Thoughts on the break-up (and any of the topics from the weekly mail)
> are very welcome.
> >
> > Finally, correcting the typo above -- the final example should have been:
> >
> > target-machine% llvm-jitlink-executor listen=localhost:20000
> > jit-machine% llvm-jitlink -oop-executor-connect localhost:20000
> hello-world.o
> > hello world!
> >
> > -- Lang.
> >
> > On Sun, Sep 13, 2020 at 11:01 PM Lang Hames <lhames at gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> Everything is landing all at once, just not in the mainline... yet.
> >>
> >> As discussed in
> http://lists.llvm.org/pipermail/llvm-dev/2020-September/144885.html:
> OrcV1 will be removed very soon. I have posted a branch with the removal,
> "orcv1-removal", in my llvm fork at https://github.com/lhames/llvm-project
> .
> >>
> >> In addition to removing OrcV1, the orcv1-removal branch also contains a
> prototype of the removable code feature. I'm going to discuss this at
> greater length over the next couple of weeks, but if anyone's interested in
> playing with the prototype I'd recommend starting with the ResourceTracker
> class in
> https://github.com/lhames/llvm-project/commit/de6f6d57d3e955b998f82ab6e610da41fcb09492
> .
> >>
> >> Finally, adding removable code unblocked another prototype I've been
> working on: an OrcRPC based TargetProcessControl implementation. I've added
> that to the "orcv1-removal-with-remote-tpc" branch at
> https://github.com/lhames/llvm-project. The easiest way to start playing
> with this feature is via the new llvm-jitlink options: -oop-executor, and
> -oop-executor-connect. The -oop-executor option will fork and exec the
> llvm-jitlink-executor program and connect to it via open file descriptors
> (similar to how lli-child-target works). The -oop-executor-connect option
> will connect to a listening llvm-jitlink-executor process via TCP, but
> otherwise behaves the same. E.g.
> >>
> >> % llvm-jitlink -oop-executor hello-world.o
> >> hello world!
> >>
> >> target-machine% llvm-jitlink-executor listen=localhost:20000
> >> jit-machine% llvm-jitlink -oop-executor-connect localhost:2000
> hello-world.o
> >> hello world!
> >>
> >> How all this works is left as an exercise for the reader this week. I
> can start providing explanations in my next update.
> >>
> >> -- Lang.
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://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/20200914/c48ef724/attachment.html>