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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200913/1610965c/attachment.html>

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200914/3e0544c1/attachment.html>

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


-- 
宋方睿