[LLVMdev] Loads/Stores and MachineMemOperand

[Heikki Kultala]

On 11 Dec 2012, at 21:00, Justin Holewinski wrote:

> 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.  
> 
> 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.
> 
> 
> 518         if (!V || !isa<AllocaInst>(V)) {
> 519           // Clear mem operand since we don't know for sure that it doesn't                                                                                                                      
> 520           // alias a merged alloca.                                                                                                                                                              
> 521           MMO->setValue(0);
> 522           continue;
> 523         }

Thanks for finding this.

I've been trying to find out why multiple address space support breaks/bugs with llvm 3.2 and this looks like it is the reason for that;
Some memory operations lose the information about their address space which is stored in the value of the MachineMemOperand.

Clearing the value seems to be a very nasty thing to do, what is the meaning of this code?