<div>I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions.  From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands.  </div>
<div><br></div><div>But what is the guarantee/constraint placed on optimization/codegen passes for maintaining the contents of a MachineMemOperand?  In particular, a MachineMemOperand has a Value associated with it for the original LLVM IR pointer, but is there any guarantee that this will be valid for *all* memory-touching instructions after isel and post-isel optimization?  I found the following code in StackColoring that seems to indicate that one should not rely on the Value* in a MachineMemOperand to get at pointer information like address space during instruction printing since it may be NULL.<br>
</div><div><br></div><div><br></div><div>518         if (!V || !isa<AllocaInst>(V)) {</div><div>519           // Clear mem operand since we don't know for sure that it doesn't                                                                                                                      </div>
<div>520           // alias a merged alloca.                                                                                                                                                              </div><div>521           MMO->setValue(0);</div>
<div>522           continue;</div><div>523         }</div><div><br></div><div><br></div><div>Is this just a deficiency in the optimizer, or is there no guarantee that MachineMemOperand will retain a valid Value* instance through-out its lifetime?</div>
<div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>