Relationship between MachineMemOperand and X86II::getMemoryOperandNo

Hello,

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.

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?

Thanks,
Mircea.

Hello Mircea,

Hello,

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)

bb.0:
  liveins: $rax
  $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)

Cheers,

Thanks for the details!

How should we think of the case where an instruction has memory operands (in the sense that X86II::getMemoryOperandNo >=0), but doesn’t have MachineMemOperands?

I’m seeing an example in the case of __builtin_prefetch (lowered via SelectionDAG::getMemIntrinsicNode, which produces a MachineMemOperand) vs __builtin_ia32_gatherpfdpd, lowered through getPrefetchNode in X86ISelLowering.cpp. The latter doesn’t have a MachineMemOperand.

Is the latter technically a bug, maybe, and it so happens nothing is hindered by the absence of the MachineMemOperand, so we’re not observing it?

Added Elena, based on commit log in X86ISelLowering.cpp, perhaps she has more context.

Thanks!Mircea

Hi Mircea,

Thanks for the details!

How should we think of the case where an instruction has memory operands (in the sense that X86II::getMemoryOperandNo >=0), but doesn’t have MachineMemOperands?

I am not sure if this rule is enforced throughout the code generator, but I can see that some places like here (https://github.com/llvm-mirror/llvm/blob/12d5807/lib/CodeGen/MachineInstr.cpp#L1082) and here (https://github.com/llvm-mirror/llvm/blob/12d5807/lib/CodeGen/MachineLICM.cpp#L881), we conservatively assume that if there are no memory operands, we follow the mayLoad / mayStore flags from the instruction description.

I’m seeing an example in the case of __builtin_prefetch (lowered via SelectionDAG::getMemIntrinsicNode, which produces a MachineMemOperand) vs __builtin_ia32_gatherpfdpd, lowered through getPrefetchNode in X86ISelLowering.cpp. The latter doesn’t have a MachineMemOperand.

Is the latter technically a bug, maybe, and it so happens nothing is hindered by the absence of the MachineMemOperand, so we’re not observing it?

If what I said above is true (I’m not completely sure either), I suppose adding MachineMemOperands while lowering would allow for more optimizations to kick in.

Thanks,