[llvm-dev] Any plan to implement JIT for RISC-V ?
Du Chao via llvm-dev
pawel k. via llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Stefan Gränitz via llvm-dev
The vast majority of code was written by Lang Hames (cc). I had the opportunity to help with a few details in the ELF implementation and I am familiar with most of the relevant JIT parts. Adding a backend for a new arch, however, requires decent domain knowledge. If there's an effort to make one, I am happy to join, but it's a little more than a spare time project.
_______________________________________________ LLVM Developers mailing list llvm...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Lang Hames via llvm-dev
Martin Troiber via llvm-dev
Since someone already started with the JIT implementation for RISCV I
was wondering which steps are missing.
Is there a series of commits for x86 or ARM to take inspiration from?
What is the current state of llvm-jitlink on RISCV?
Aside from jitlink what is missing to make the "Building a JIT" tutorial
fully functional?
On top of that what is missing for lli?
I would be interested in helping with this effort so a few pointers in
the right direction would be great.
Best wishes
Martin
On 17.07.21 08:35, llvm-dev at lists.llvm.org (Lang Hames via llvm-dev)
wrote:
> Hi All,
>
> Someone submitted a review for a JITLink RISCV implementation recently --
> https://reviews.llvm.org/D105429. Was this one of you? :)
>
> -- Lang.
>
> On Thu, Apr 22, 2021 at 6:15 AM Stefan Gränitz <stefan.graenitz at gmail.com>
> wrote:
>
>> As codegen exists for RISCV, this comes down to providing a proper link
>> step I believe. For the longest time LLVM JIT used RuntimeDyld for it, but
>> it hasn't seen many extensions recently. JITLink has backends for MachO
>> x86-64/ARM64 and ELF x86-64 currently. I think ELF ARM32/64 are highly
>> desirable and there seems to be interest in a COFF backend as well. I like
>> the idea of adding RISCV here!
>>
>> The vast majority of code was written by Lang Hames (cc). I had the
>> opportunity to help with a few details in the ELF implementation and I am
>> familiar with most of the relevant JIT parts. Adding a backend for a new
>> arch, however, requires decent domain knowledge. If there's an effort to
>> make one, I am happy to join, but it's a little more than a spare time
>> project.
>>
>> On 21/04/2021 05:47, Du Chao via llvm-dev wrote:
>>
>> Hi all,
>>
>> May I know if there is any plan to add RISCV support in LLVM JIT ?
>>
>> Regards,
>> Du Chao
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> -- https://weliveindetail.github.io/blog/about/
Stefan Gränitz via llvm-dev
some pointers. Please note that it's likely incomplete.
> Aside from jitlink what is missing to make the "Building a JIT"
> tutorial fully functional?
Some details here:
https://llvm.org/OpenProjects.html#llvm_build_jit_tutorial
> On top of that what is missing for lli?
I think lli is maintained mostly to remain functional right now. Last
year in spring I added JITLink debug support and the ORC greedy mode.
Since then it doesn't seem so much has happened [1] and I don't know of
any efforts to refactor outdated code or bring up new ORC/JITLink
features. The latter are rather exposed via the llvm-jitlink tool [2].
[1] https://github.com/llvm/llvm-project/commits/main/llvm/tools/lli/lli.cpp
[2]
https://github.com/llvm/llvm-project/commits/main/llvm/tools/llvm-jitlink/llvm-jitlink.cpp
> Since someone already started with the JIT implementation for RISCV I
> was wondering which steps are missing.
Here's a few things I am aware of. I am sure @Stephen and @Lang (cc) can
add more:
* The llvm-jitlink tool is missing a `registerRISCVGraphInfo()`
implementation. Its session dumps will be incomplete:
https://github.com/llvm/llvm-project/blob/49f23afdc3453ad6834f32f69b48aa88b5d17338/llvm/tools/llvm-jitlink/llvm-jitlink.cpp#L1074
* Only a hand-full of relocations were implemented so far [3].
BinaryFormat has a list of all relocations known to LLVM [4].
[3]
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ExecutionEngine/JITLink/riscv.h
[4]
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
* There is no optimization pass that would relax unnecessary GOT and PLT
stubs [5]. Usually, stubs are allocated for relative relocations that A:
can overflow (i.e. target address out of range) and/or B: might change
(e.g. for hot code optimizations). Both, ELF and MachO implementations
for x86_64 do support it to some degree [6]. In context of RISCV it
might be interesting to combine this with the next item.
[5] https://reviews.llvm.org/D107688
[6]
https://github.com/llvm/llvm-project/commit/cc3115cd1d35b7325d4f1d53f860048e32e82e43
* None of the JIT backends has a way to track which GOT and PLT stubs
are actually in use (not relaxed at link-time) and which ones are not in
use (have been relaxed). I think the latter should be reusable for stubs
in subsequent link graphs in order to allow clients to save a few bytes
of memory in cases where it matters.
> Is there a series of commits for x86 or ARM to take inspiration from?
Not really. I started an Aarch64 implementation in August [7], but so
far didn't find the time to continue working on it. Other people's
attempts to extend it weren't successful yet [8]. IMHO the biggest
showstopper at this point is the complexity of tests. Under the hood
#jitlink-check lines in LIT tests use RuntimeDyldChecker which is,
basically, undocumented [9].
[7] https://reviews.llvm.org/D108986
[8] https://reviews.llvm.org/D112451
[9] https://reviews.llvm.org/D112451#inline-1072133
I hope it helps. If you want to work on any of this or you want to
discuss things in more detail, you might want to join the #jit channel
in LLVM Discord:
https://discord.gg/SsDVj7Bf
Cheers,
Stefan
Martin Troiber via llvm-dev
Thank you for the rundown of the current state.
I would definitely be interested in working on the JIT for RISC-V since
it's a dependency for a research project that I'm working on. The aim is
to use a Software-Renderer on RISC-V and the popular ones (Swiftshader
and Lllvmpipe) use LLVM JIT to translate SPIR-V to machine code. I
joined the discord but I'm still posting the response here so it's
visible for other people as well. We can talk about the details on discord.
Regarding lli I just wanted to make sure I understood it properly:
- Lli uses the same ORC internals (for linking) as llvm-jitlink but
exposes less linking related features.
- If Swiftshader and Llvmpipe internally build a custom ORC-based JIT
then I don't have to worry about lli anyways.
Regarding the missing llvm-jitlink pieces:
- I'm not sure what you are referring to with
`registerRISCVGraphInfo()`. Using `show-graph`, `show-sizes`,
`show-relocated-section-contents` work as expected as it's just using
the regular `registerELFGraphInfo()` like the other platforms.
- In terms of the not yet supported relocations is there a good order to
implement them in? Maybe the quickest way to make a "hello world"
compiled with clang and linked with llvm-jitlink + the "Building a JIT
tutorial" functional. Currently both of those lead to segmentation faults.
- If optimization passes and GOT/PLT tracking are more of a nice to have
then I'd look into that once I'm more familiar with the other missing
pieces.
What do you think could be a good first step to get going with this
project?
I'm currently at the stage where I can build, modify and test the
existing relocations on my RISC-V QEMU system.
Best wishes
Martin
Am 04.01.22 um 15:31 schrieb Stefan Gränitz: