[llvm-dev] Any plan to implement JIT for RISC-V ?

Sun Jan 9 09:19:10 PST 2022

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

Am 04.01.22 um 15:31 schrieb Stefan Gränitz:
> 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
>
> On 29/12/2021 19:29, Martin Troiber via llvm-dev wrote:
>> 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
>>
>> 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/
>>>>
>>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>