PPC LLVM 18

[Rot127]

Your checklist for this pull request

• I've documented or updated the documentation of every API function and struct this PR changes.
• I've added tests that prove my fix is effective or that my feature works (if possible)

Detailed description

New

(According to LLVM changelog)

• Added DFP instruction.
• Added the SCV instruction.

Changes

• The MCUpdater generates shorter and better readable file names.
• Memory decoder were simplified by decoding disponent and base reg separately.
• DFORM -> DFORM_BASE
• Use inverted MCInstDesc table.
• Replace the many declared printer in PPCInstPrinter with static inlines.
• Renamed groups to upper case.
• Switched to ARCH_add_cs_detail_X() function names.
• Remove PPCInstPrinter.h because it is no longer used.
• Absolute addresses are printed as unsigned immediate, not as signed.
• Be way more strict about enabled CPU features and architectures.
• Adds Power7-Power10 + Future ISA CPUs.
• Adds and moves multiple features for PPC CPUs:
  • +aix Enables AIX OS assembly (only: PowerPC)
  • +booke Enables BOOKE extension (only: PowerPC)
  • +maix Enables Modern AIX assembly (only: PowerPC)
  • +msync Has only the msync instruction instead of sync. Implies BookE. (only: PowerPC)
  • +qpx Enables QPX extension (only: PowerPC)
  • +ps Enables PS extension (only: PowerPC)
  • +spe Enables SPE extension (only: PowerPC)

Test plan

Newly added and all green.

Closing issues

...

[XVilka]

@kabeor take a look at this one please

[hainest]

Huge thanks for doing this. It looks like LLVM is choosing to only implement either an X-form or a D-form of some instructions[1]. It would be nice to have both forms, but that would require manual tracking. Is there a mechanism in the auto-sync importer to do this? I'd be happy to submit a PR for that.

[1] See dyninst/dyninst@64cec85 for a few examples based on v3.1C of the standard.

[Rot127]

@hainest Do you have two example byte strings for testing. One in X one in D form? Then I can check how they decode.

[hainest]

Let me run them through an assembler. I just realized that it might actually be a difference in regular versus extended mnemonics.

[kabeor]

Amazing!

[Rot127]

@hainest I currently fix some regressions of this one and checked one example from the link you provided. LLVM seemed to implement only the XFORM?

defm DENBCD: XForm_S1_FRTB5r<59, 834, (outs f8rc:$FRT),
                              (ins u1imm:$S, f8rc:$FRB),
                              "denbcd", "$S, $FRT, $FRB", []>;
defm DENBCDQ: XForm_S1_FRTB5r<63, 834, (outs fpairrc:$FRT),
                               (ins u1imm:$S, fpairrc:$FRB),

It would be nice if you open an issue about it, if you find some.
Maybe it is due to the definition of them in the td files. Making some isPseudo or CodeGenOnly or similar.

[Rot127]

@hainest Off-topic. But I see your tool also seems to use Capstone quite extensively. If you have any work arounds for buggy instruction details, I would be really happy if you can open issues about it. One issue to collect all of them is fine.
I try to improve the test coverage.

[hainest]

@hainest I currently fix some regressions of this one and checked one example from the link you provided. LLVM seemed to impleemnt only the XFORM?

defm DENBCD: XForm_S1_FRTB5r<59, 834, (outs f8rc:$FRT),
                              (ins u1imm:$S, f8rc:$FRB),
                              "denbcd", "$S, $FRT, $FRB", []>;
defm DENBCDQ: XForm_S1_FRTB5r<63, 834, (outs fpairrc:$FRT),
                               (ins u1imm:$S, fpairrc:$FRB),

It would be nice if you open an issue about it, if you find some. Maybe it is due to the definition of them in the td files. Making some isPseudo or CodeGenOnly or similar.

So sorry, I've been inundated with fixing bugs. I will try to take a look at these over the weekend and get you some more details. I'll open an issue once I have something concrete.

[hainest]

@hainest Off-topic. But I see your tool also seems to use Capstone quite extensively. If you have any work arounds for buggy instruction details, I would be really happy if you can open issues about it. One issue to collect all of them is fine. I try to improve the test coverage.

Yes. I have some x86 instruction semantics that I'd like to add. I have three more instructions to analyze before I'm read to submit them. That said, I am very much in favor of integrating Zydis into Capstone. It's just too much work to keep track of the x86 instructions. I have confirmed that the missing semantics I found are present in Zydis.

[hainest]

I have confirmed all but two of the instructions that I previously marked as 'missing' are now present and can be decoded by 5f290ca. 'dcffixqq' and 'dctfixqq' weren't available on the binutils I have access to, but they are in Capstone's decode tables. I haven't confirmed if they work. I've attached an assembly example so someone could write tests for these. I don't have the cycles to go through that detail of the manual right now.

opcodes.tar.gz

[Rot127]

Ok, thanks for reporting back!