This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objdump][RISCV] Print target of auipc+jalr calls
AbandonedPublic

Authored by jobnoorman on Aug 29 2023, 8:35 AM.

Details

Summary

Currently, the targets of auipc+jalr calls are not printed because
MCInstrAnalysis fails to analyze them. This patch implements this as follows:

  • Add a new MCInstrAnalysis::evaluateBranch overload that takes two consecutive instructions as arguments. This allows the RISC-V backend to detect auipc+jalr sequences.
  • While disassembling in llvm-objdump, keep track of the previous instruction and call the new evaluateBranch overload.

Note that the new evaluateBranch overload could have been avoided by making
PrevInst an argument of the existing version and giving it a default value.
However, this would have made it necessary to update nearly all targets so I
will keep this refactoring to a future patch.

Diff Detail

Event Timeline

jobnoorman created this revision.Aug 29 2023, 8:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 29 2023, 8:35 AM
jobnoorman requested review of this revision.Aug 29 2023, 8:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 29 2023, 8:35 AM
arichardson added inline comments.Aug 29 2023, 10:45 PM
llvm/include/llvm/MC/MCInstrAnalysis.h
173

How about passing the optional PrevInst to to the existing evaluateBranch() instead? Having to choose which overload to implement is bit awkward and means two calls per instruction instead of just one.

jobnoorman updated this revision to Diff 554628.EditedAug 30 2023, 1:40 AM
jobnoorman edited the summary of this revision. (Show Details)

Update the evaluateBranch overload to take PrevInst as a std::optional.
The default implementation falls back to the existing evaluateBranch. This
simplifies its use in llvm-objdump as now only a single evaluateBranch call is
needed.

Thanks for the suggestion @arichardson! Note that I didn't add the std::optional
argument to the existing evaluateBranch but created a new overload instead.
This is to avoid having to update nearly all targets in this patch. I will
propose a refactoring once this gets accepted.

jobnoorman marked an inline comment as done.Aug 30 2023, 1:41 AM

I think in recent years @asb has a similar patch in this area but I cannot find it...

jobnoorman abandoned this revision.Sep 6 2023, 6:48 AM

I think in recent years @asb has a similar patch in this area but I cannot find it...

Indeed, it's D116677. I've opened #65479 to implement the state idea discussed there and #65480 to implement it for auipc+jalr on RISC-V.

I will close this review in favor of the new PRs.