Page MenuHomePhabricator

[RuntimeDyld][RISCV] Minimal riscv64 support
Needs ReviewPublic

Authored by dnpetrov-sc on Jun 15 2022, 3:13 AM.

Details

Reviewers
lhames
asb
Summary

llvm-exegesis uses JIT to compile synthetic code snippets.

Focus of this patch is to provide support necessary for llvm-exegesis to work on the riscv64 platform.
It also fixes the following LLVM-Unit OrcJIT tests on riscv64:

ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.AddObjectBuffer
ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.ExecutionTest
ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.ResourceTrackerDefinitionLifetime
ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.ResourceTrackerTransfer

Some of the OrcJIT tests keep failing on riscv64, just with a different message - unimplemented relocation type X instead of unsupported processor type.

NB I don't have commit access to the LLVM repo, so someone should commit on my behalf.

Diff Detail

Event Timeline

dnpetrov-sc created this revision.Jun 15 2022, 3:13 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 15 2022, 3:13 AM
dnpetrov-sc requested review of this revision.Jun 15 2022, 3:13 AM
dnpetrov-sc edited the summary of this revision. (Show Details)Jun 15 2022, 3:15 AM

Thanks very much for raising this issue Dmitrii. We actually have relatively advanced RISCV support JITLink now, but it doesn't look like llvm-exegesis is using it. We should aim to update the llvm-exegesis tool, rather than RuntimeDyld. Do you know who is responsible for that tool these days?

Some of the OrcJIT tests keep failing on riscv64, just with a different message - unimplemented relocation type X instead of unsupported processor type.

Can you share the failure message and context? This may be of interest to @StephenFan.

@courbet Are you the right person to talk to about the llvm-exegesis tool? Can it be moved over to ORC/JITLink?

It doesn't look like it's using any of the JITEventListeners, so I'm hoping we can just switch to LLJIT (maybe with some conditional hacks to support getting the function range in RuntimeDyld vs JITLink). Does that sound reasonable?

Thanks very much for raising this issue Dmitrii. We actually have relatively advanced RISCV support JITLink now, but it doesn't look like llvm-exegesis is using it. We should aim to update the llvm-exegesis tool, rather than RuntimeDyld. Do you know who is responsible for that tool these days?

Some of the OrcJIT tests keep failing on riscv64, just with a different message - unimplemented relocation type X instead of unsupported processor type.

Can you share the failure message and context? This may be of interest to @StephenFan.

Build on riscv64, run ExecutionEngine tests.
'main' fails with fatal error "Unsupported CPU type!" (in RuntimeDyldELF::resolveRelocation, RuntimeDyldELF.cpp:1076) in the following tests:

ExecutionEngine/frem.ll
ExecutionEngine/mov64zext32.ll
ExecutionEngine/test-interp-vec-arithm_float.ll
ExecutionEngine/test-interp-vec-arithm_int.ll
ExecutionEngine/test-interp-vec-logical.ll
ExecutionEngine/test-interp-vec-setcond-fp.ll
ExecutionEngine/test-interp-vec-setcond-int.ll
ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.AddObjectBuffer
ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.ExecutionTest
ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.ResourceTrackerDefinitionLifetime
ExecutionEngine/Orc/./OrcJITTests/OrcCAPITestBase.ResourceTrackerTransfer

Side note: it looks like there's a bug in ELFJITLinker_riscv::applyFixup (ELF_riscv.cpp:375):

case R_RISCV_SUB6: {
  int64_t Value =
      *(reinterpret_cast<const uint8_t *>(FixupAddress.getValue())) &
      0x3f - E.getTarget().getAddress().getValue() - E.getAddend();
  *FixupPtr = (*FixupPtr & 0xc0) | (static_cast<uint8_t>(Value) & 0x3f);
  break;
}

& has lower priority. That should be (<old value> & <mask>) - <offset>, but actually is <old value> & (<mask> - <offset>), which doesn't look right. I don't have a reproducer on hand, though.

@courbet Are you the right person to talk to about the llvm-exegesis tool? Can it be moved over to ORC/JITLink?

I am. What we require is being able to work at the MC rather and IR level, because we want exact control over which instructions are emitted I'm not familiar with ORCJit, but from a quick look at the doc it looks like it should be doable: replacements for earlier LLVM JIT APIs (e.g. MCJIT).

Is MCJIT going away ?

yakush added a subscriber: yakush.Jun 16 2022, 3:43 AM

@courbet Are you the right person to talk to about the llvm-exegesis tool? Can it be moved over to ORC/JITLink?

I am. What we require is being able to work at the MC rather and IR level, because we want exact control over which instructions are emitted I'm not familiar with ORCJit, but from a quick look at the doc it looks like it should be doable: replacements for earlier LLVM JIT APIs (e.g. MCJIT).

Yep -- you can definitely load up object files directly.

Is MCJIT going away ?

We don't have plans to remove it any time soon, but it's no longer being actively developed.

asb added a comment.Jun 20 2022, 2:19 AM

I'm not very familiar with testing for RuntimeDyld, but shouldn't there be test cases added to llvm/test/ExecutionEngine/RuntimeDyld/RISCV to cover this change? (also - thanks for the contribution!)