How to test metadata update in backend? MIR tests prints pointer value


Backend might need to create / modify MachineInstr metadata.

Actual case we met

User provided properties of loop trip count in loop metadata. Backend pass changes actual trip count and it must delete / update this property because it was invalidated. For now there is no way to write any MIR test for that pass.

Any MIR test prints check for the pointer to the updated MachineInstr metadata. llvm/utils/ script will generate something like that:

; CHECK:   JMPR %bb.8, $sp1, 0, <0x56243d106ca0>

<0x56243d106ca0> is a pointer to created / updated metadata node.

Why there is a pointer?
Print happens for MachineOperand class instance with metadata here:

static void WriteAsOperandInternal(raw_ostream &Out, const Metadata *MD,
   int Slot = Machine->getMetadataSlot(N);
   if (Slot == -1) {
     if (const DILocation *Loc = dyn_cast<DILocation>(N)) {
       writeDILocation(Out, Loc, TypePrinter, Machine, Context);
     // Give the pointer value instead of "badref", since this comes up all
     // the time when debugging.
     Out << "<" << N << ">";
   } else
     Out << '!' << Slot;

There is no slot assigned for the new metadata. Checking the slot assingment function:

inline void SlotTracker::initializeIfNeeded() {
 if (TheModule) {
   TheModule = nullptr; ///< Prevent re-processing next time we're called.

 if (TheFunction && !FunctionProcessed)

If we go deeper, we find that slots are created for middle-end Functions metadata and Instructions metadata, but backend MachineFunction and MachineInstr are ignored. No slot - no print.

During backend passes metadata should be created / updated on backend level, and attached to MachineInstr.

There are two problems arise:

  1. Less important, MIR testing technique does not allow to check that metadata is updated properly.
  2. More importat, there is no way to write any MIR test which triggers metadata creation / update scenario, because AsmPrinter emits raw pointer value which is different from run to run.

Problem 2 requires some workarounds like special command line options to disable metadata modification for testing or something like that. It seems like a not clean code.


  • How do you solve such problems? Are there known solution?
  • Should SlotTracker take into account MachineFunction content and enumerate MachineInstrs?
  • If yes, should I backport MachineInstrs enumeration in SlotTracker to llvm repo?

Thank you