I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions.
MachineMemOperands are used to represent memory references, so that the (generic) code generator can reason about their dependencies and aliases.
You can see them when:
* you call MachineInstr::dump (llc -print-after-all, etc.), at the end of the instruction, there is a "; mem:LD4..."
* using MIR (llc -stop-before/-run-pass/etc.), at the end of the instruction, ":: (load 4…)”
* using llc -asm-verbose, they are emitted as comments "# 4-byte Reload”
MachineInstrs will have multiple operands, ex:
%5 = MOV64rm %0, 1, $noreg, 0, $noreg
and in order to know which operand is what, the X86 backend uses some enums and helper functions so that they can write code like:
const MachineOperand &BaseReg = MI->getOperand(Op+X86::AddrBaseReg);
const MCOperand &BaseReg = MI.getOperand(Op+X86::AddrBaseReg);
for both MachineInstrs and MCInsts.
Is it possible to have a X86 MachineInstr with a memory operand (i.e. X86II::getMemoryOperandNo >=0), that has no MachineMemOperand? What about the reverse?
* Attaching a MachineMemOperand to an instruction that doesn’t reference any memory:
From what I tried, the instruction has to be marked as “mayLoad / mayStore” (you can see them in X86InstrInfo.td) in order to pass the verifier:
$rbx = MOV64rr $rax :: (load 4)
$rbx = MOV64rr $rax; mem:LD4[<unknown>]
# End machine code for function foo.
*** Bad machine code: Missing mayLoad flag ***
- function: foo
- basic block: %bb.0 (0x7fc884017678)
- instruction: $rbx = MOV64rr $rax; mem:LD4[<unknown>]
LLVM ERROR: Found 1 machine code errors.
* Memory-touching MachineInstrs without MachineMemOperands:
$rbx = MOV64rm _, 1, _, 0, _
This is allowed.
(anyone, please correct me if I’m wrong on anything here)