[PATCH] D146438: [RISCV][MC] Refine MCInstrAnalysis based on registers used
Job Noorman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 21 03:22:02 PDT 2023
jobnoorman added inline comments.
================
Comment at: llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCTargetDesc.cpp:168
+ case RISCV::JALR:
+ return Inst.getOperand(0).getReg() == RISCV::X1;
+ }
----------------
pcwang-thead wrote:
> What about `call t0, OUTLINED_FUNCTION` where register is `RISCV::X5`?
It's an interesting question whether we should handle outlined function calls here. I'd say it makes sense to do so but I would like to hear some more opinions about this.
We could also consider returning true for all JAL/JALR instructions where RD!=X0. The reasoning being that if the return address is stored anywhere, it's probably a function call.
================
Comment at: llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCTargetDesc.cpp:180
+ case RISCV::JALR:
+ return Inst.getOperand(0).getReg() == RISCV::X0 &&
+ Inst.getOperand(1).getReg() == RISCV::X1;
----------------
pcwang-thead wrote:
> What about `jalr x0, x5` which is used in outlined function?
If we decide to do the same for `isCall`, this could make sense for consistency. However, I'm a bit afraid that many indirect branches that happen to use X5 will be incorrectly recognized as returns.
Since both `isCall` and `isReturn` can only be estimates on RISC-V given just a single `MCInst`, the question is whether we want to over- or underestimate. I personally lean towards underestimating since returns are, in general, easy to detect on most targets. So giving a lot of false positives here might trip-up tools using this API.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D146438/new/
https://reviews.llvm.org/D146438
More information about the llvm-commits
mailing list