The code itself makes sense, but I want to know if this breaks any guarantee made about preserving a Value* in the MachineMemOperand.  It sounds like we're having the same issue.  We were using the Value* stored in the MachineMemOperand to get address space information during assembly printing.  The alternative is carrying around a lot of extra (redundant) information in the SDAG.<div>
<br></div><div>If it is legal to clear the Value* instead of replacing it with something else, perhaps we can add the address space as another field to the MachineMemOperand.  If the Value* gets cleared, at least that would still be available, and I cannot imagine any transformation that would cause the pointer address space to change.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 11, 2012 at 2:52 PM, Heikki Kultala <span dir="ltr"><<a href="mailto:hkultala@cs.tut.fi" target="_blank">hkultala@cs.tut.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 11 Dec 2012, at 21:00, Justin Holewinski wrote:<br>
<br>
> 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.<br>

><br>
> 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>

><br>
><br>
> 518         if (!V || !isa<AllocaInst>(V)) {<br>
> 519           // Clear mem operand since we don't know for sure that it doesn't<br>
> 520           // alias a merged alloca.<br>
> 521           MMO->setValue(0);<br>
> 522           continue;<br>
> 523         }<br>
<br>
</div>Thanks for finding this.<br>
<br>
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;<br>
Some memory operations lose the information about their address space which is stored in the value of the MachineMemOperand.<br>
<br>
Clearing the value seems to be a very nasty thing to do, what is the meaning of this code?<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>
</div>