Looking through the X86 GlobalISEL code for selecting loads and stores, I'm not seeing the creation of the MachineMemOperands I'd expect to see and do see being generated by SelectionDAG. Is this simply an oversight, or is there some aspect of the new design which pushes us away from MMOs?
Various parts of the machine instruction level optimization passes use the existence and contents of an MMO for optimization legality checks. As a simple example, we won't fold a load unless we can examine it's MMO to ensure the access is not volatile. At the moment, this would seem to mean that GlobalISEL generated code can't have load folding done by the PeepholeOptimizer. Unless I'm missing something? I'm very new to GlobalISEL.
MMOs are still required in GlobalISel. Looking at X86InstructionSelector::selectLoadStoreOp(), it seems that X86 is selecting their load instructions using MachineInstr::setDesc(). This mutates the existing instruction and keeps the existing MMOs that were on the original G_LOAD.
I'm guessing this comes down to user error. I tried reproducing this again, and saw the MMO as expected. I'm guessing I got confused by not seeing the handling in the X86 code due to the mutation approach, and then misreading the debug output or something.
Sorry for the noise, and thanks for the quick response.