Machine instructions today can be marked as "mayLoad" or "mayStore" to indicate memory accesses. If there is a MachineMemOperand attached to the an instruction so marked, its properties will further restrict the type of memory access performed, but it there is no such operand, the instruction will be assumed to load from or store to any part of memory.
The new flag mayAccessMemory introduced here has somewhat different semantics. If there is a MachineMemOperand attached to the instruction, the instruction will be assumed to access the memory described by the operand (as if there were a mayLoad/mayStore). But if there is no such operand, then the instruction will instead be assumed to have no memory-related side effect.
This allows defining instructions that *optionally* access memory. The plan is use this to implement strict floating-point handling in the back end (as part of https://reviews.llvm.org/D45576). A target may mark floating-point instructions as "mayAccessMemory". The common code DAG expansion will add a MachineMemOperand (refering a floating-point status PseudoSourceValue marker) to the instruction if strict FP operation is desired, but will add no such operand for regular (non-strict) FP operations. This means that the usual memory access logic will create the required dependencies for strict operations, but no such dependencies for regular operations -- allowing a target to handle both cases without duplicating all FP insn definitions.