Any plan to implement JIT for RISC-V ?

Hi all,

May I know if there is any plan to add RISCV support in LLVM JIT ?

Regards,
Du Chao

Hi,
Whats intended use? Also can You point me in direction of what is this component good for and how hard would it be? Interested in complangs jits and essentially interested in riscv.

Best regards,
Pawel Kunio

śr., 21.04.2021, 05:47 użytkownik Du Chao via llvm-dev <llvm-dev@lists.llvm.org> napisał:

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.

Hi All,

Someone submitted a review for a JITLink RISCV implementation recently – https://reviews.llvm.org/D105429. Was this one of you? :slight_smile:

– Lang.

Hi all,

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

Hi Martin, this is a great question. Let me try to provide some info and 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

Hi Stefan,

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