[RuntimeDyld] Add LoongArch support #114741
Conversation
Created using spr 1.3.5-bogner
There was a problem hiding this comment.
Hi @lhames, we know MCJIT/RuntimeDyld are going to be removed, but this change is necessary to get LoongArch support in lldb (#114742). And LoongArch has already supported ORCJIT and JITLink and it has been verified in production environments (e.g. mesa3d llvmpipe). That means lldb can switch to ORCJIT/JITLink before MCJIT/RuntimeDyld being removed without breaking LoongArch support.
I hope this could be reviewed and merged. Thanks. :)
| unsigned RelType = RelI->getType(); | ||
| // Look for an existing stub. | ||
| StubMap::const_iterator i = Stubs.find(Value); | ||
| if (i != Stubs.end()) { |
There was a problem hiding this comment.
This logic might be easier to parse if it was organised like this:
if (i != Stubs.end()) {
// resolve using the stub
return;
}
if (resolveLoongArch64ShortBranch(SectionID, RelI, Value))
return;
// Create a new stub function.
LLVM_DEBUG(dbgs() << " Create a new stub function\n");
Same logic, but it's easier to see that all paths will resolve the relocation in some way.
Also do you want to prefer stubs over a short branch if you could use one? That seems to be what this does, but I don't know enough about JIT to say if that makes sense.
My assumption is that anything that could be resolved by a short branch would never have needed a stub, so looking for a stub for it will always fail. Perhaps sometimes the same location must be reached via a stub if you are too far away, but if you are close enough for a short branch wouldn't that be the most efficient option?
There was a problem hiding this comment.
Thank you very much; I will revise it to a clearer logic.
| // Returns extract bits Val[Hi:Lo]. | ||
| static inline uint32_t extractBits(uint64_t Val, uint32_t Hi, uint32_t Lo) { | ||
| return Hi == 63 ? Val >> Lo : (Val & (((1ULL << (Hi + 1)) - 1))) >> Lo; | ||
| } |
There was a problem hiding this comment.
I would have thought we would have this in llvm's utility headers somewhere but I couldn't find one. llvm/include/llvm/Support/MathExtras.h is closest but it only has upper and lower 32 bits.
There was a problem hiding this comment.
Yes, it needs to support extracting the entire 64-bit number.
Created using spr 1.3.5-bogner
There was a problem hiding this comment.
Hi @lhames, we know MCJIT/RuntimeDyld are going to be removed, but this change is necessary to get LoongArch support in lldb (#114742).
We're actually working to get LLDB moved over to ORC, but that will take a little while. This seems like a reasonable step in the mean time. Thanks for working on this @wangleiat !
wangleiat
deleted the
users/wangleiat/spr/runtimedyld-add-loongarch-support
branch
This patch adds desired feature flags in JIT compiler to enable hard-float instructions if target supports them and allows to use floats and doubles in lldb expressions. Fited tests: lldb-shell :: Expr/TestAnonNamespaceParamFunc.cpp lldb-shell :: Expr/TestIRMemoryMap.test lldb-shell :: Expr/TestStringLiteralExpr.test lldb-shell :: SymbolFile/DWARF/debug-types-expressions.test Similar as #99336 Depens on: #114741 Reviewed By: SixWeining Pull Request: #114742
This is necessary for supporting function calls in LLDB expressions for LoongArch. This patch is inspired by llvm#99336 and simply extracts the parts related to RuntimeDyld. Reviewed By: lhames Pull Request: llvm#114741
This patch adds desired feature flags in JIT compiler to enable hard-float instructions if target supports them and allows to use floats and doubles in lldb expressions. Fited tests: lldb-shell :: Expr/TestAnonNamespaceParamFunc.cpp lldb-shell :: Expr/TestIRMemoryMap.test lldb-shell :: Expr/TestStringLiteralExpr.test lldb-shell :: SymbolFile/DWARF/debug-types-expressions.test Similar as llvm#99336 Depens on: llvm#114741 Reviewed By: SixWeining Pull Request: llvm#114742
This is necessary for supporting function calls in LLDB expressions for
LoongArch.
This patch is inspired by #99336 and simply extracts the parts related
to RuntimeDyld.