[llvm] [AMDGPU] Copy Defs and Uses from Pseudo to Real Instructions (PR #93004)

Fabian Ritter via llvm-commits llvm-commits at lists.llvm.org
Thu May 23 07:24:56 PDT 2024


ritter-x2a wrote:

@jayfoad:

> Is there any in-tree code that relies on implicit operands on Reals? Are there any in-tree tests? What's to stop this bitrotting?

I couldn't find any tests in this direction, and no test case needed adjustments for this patch to pass the lit tests.
I would expect llvm-mca to use implicit operands of Reals, but it does not seem to affect any of their AMDGPU tests either.
The llvm-mc tool does not print implicit operands of instructions.

One option I see for testing is to record the implicit operands of all instructions and introduce a test that fails if this changes.
We could for instance collect the implicit operands with the InstrDocsEmitter tablegen backend (which includes implicit operands in the documentation it generates for the instructions).
Changes to the instruction set would require updating this test.

> Does this actually change the behaviour of the compiler so that it adds extra operands to Reals in memory (either during codegen or assembly or disassembly)? Or does it jsut change the contents of the MCInstrDesc tables? I am wondering if there is any possible performance impact.

I found only two places where implicit operands are put into additional datastructures:
- In `MachineInstr`s, where they are needed for instruction selection. I wouldn't expect real instructions there.
- In llvm-exegesis, for microbenchmarks. As far as I'm aware, AMDGPU is not supported there (and if it was, correct information about implicit operands would probably be a good thing).

Other than that, the information about implicit operands of `MCInst`s only lives in the MCInstrDesc table. The getters for implicit operands only return pointers into the table.

https://github.com/llvm/llvm-project/pull/93004


More information about the llvm-commits mailing list