Add conditional and unconditional branch instructions for loongarch64.
Note that this does not include floating-point branch instructions, that will come in a later patch.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
- Does the directory lldb/source/Plugins/Instruction/LoongArch/ target both LoongArch64 and LoongArch32?
- Will you handle floating pointer branching instructions bceqz and bcnez in future?
lldb/source/Plugins/Instruction/LoongArch/EmulateInstructionLoongArch.cpp | ||
---|---|---|
205 | On LoongArch32, it should be uint32_t, right? | |
208 | On LoongArch32, it should be uint32_t, right? | |
213 | Should success be checked after call ? | |
215 | On LoongArch32, it should be llvm::SignExtend32, right? | |
258 | Return value should be checked ? | |
269 | Should it be checked ? | |
306 | Ditto. |
Yes, both LoongArch64 and LoongArch32 are supported in EmulateInstructionLoongArch
I will modify it to distinguish between LoongArch64 and LoongArch32 operations.
thank you.
- Will you handle floating pointer branching instructions bceqz and bcnez in future?
Yes, floating-point branch instructions Will be added After more test, for now add the most commonly used
branch instructions.
thank you.
(1) distinguish between LoongArch64 and LoongArch32 operations in EmulateInstructionLoongArch
(2) check the return values of some functions
Is the further work in the commit message work you intended to include in this patch? I appreciate the status update might be useful for some but commit messages are for describing what's in a commit (among other things).
If you think people might wrongly assume that this commit contains support for "floating-point branch instructions", I would write something more explicit. For example "note that this does not include <things>, that will come in a later patch".
This is all very repetitive, but that's to be expected. Whatever you can do to reduce boilerplate in future patches would be great. For example, can 32 and 64 bit variants of some instructions be emulated in the same way? Perhaps with a template parameter for the return types.
This LGTM with a few comments you can do/not do/keep in mind for future patches.
lldb/source/Plugins/Instruction/LoongArch/EmulateInstructionLoongArch.cpp | ||
---|---|---|
276 | All these could be of the form: bool EmulateInstructionLoongArch::EmulateBGEU(uint32_t inst) { return IsLoongArch64()) ? EmulateBGEU64(inst) : false; } Generally I'd advise coming up with a different way of doing this, that checks up front that you won't call EmulateBGEU and friends when you are emulating 32 bit. Perhaps some table lookup first. That said perhaps you intend to replace the else here with a call to EmulateBGEU32 in future. Up to you how to structure that. In any case I'd slim down these functions as suggested for now. | |
368 | This is what I mean about using optionals. std::optional<uint64_t> pc = ReadPC(&success); if (!pc) return false; EmulateInstruction::Context ctx; if (!WriteRegisterUnsigned(ctx, eRegisterKindLLDB, gpr_r1_loongarch, *pc + 4)) return false; It's a small saving and ok you have to * some places but when this stuff gets more complicated it can help. Anyway, up to you but keep it in mind as things get more complicated. |
lldb/source/Plugins/Instruction/LoongArch/EmulateInstructionLoongArch.cpp | ||
---|---|---|
287 | I would declare this where it is assigned. The llvm standards don't mandate that but in this case you save a line and IMO, declare as close to use is clearer. Same for rj. |
The code submissions for the EmulateInstruction section refer to some ways of riscv and sometimes record further work. You are right, should only describe what this patch does.
This patch simply separates 32 and 64 bit processing, make sure the 64-bit works properly. During the continuous
improvement of EmulateInstruction code, the details or some ways to reduce repetition you mentioned will be given
priority consideration.
Thank you very much for your detailed and reasonable suggestions.
On LoongArch32, it should be uint32_t, right?