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 }
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?
--
Thanks,
Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/63c5c4dc/attachment.html>
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?
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. 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. On Tue, Dec 11, 2012 at 2:52 PM, Heikki Kultala <hkultala at cs.tut.fi> wrote:> > 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? > > >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/320dd391/attachment.html>
On Dec 11, 2012, at 11:00 AM, Justin Holewinski <justin.holewinski at gmail.com> 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.The MMOs provide extra, optional information that late optimizers may use to combine or reorder memory operations. In particular, stripping all MMOs does not break the semantics of the program, it just removes some opportunities for optimization. A load or store without an MMO should be treated as if it were volatile. This means you probably can't use MMOs for reliable address space information. /jakob
Is this documented somewhere? On Wed, Dec 12, 2012 at 6:54 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:> > On Dec 11, 2012, at 11:00 AM, Justin Holewinski < > justin.holewinski at gmail.com> 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. > > The MMOs provide extra, optional information that late optimizers may use > to combine or reorder memory operations. > > In particular, stripping all MMOs does not break the semantics of the > program, it just removes some opportunities for optimization. > > A load or store without an MMO should be treated as if it were volatile. > > This means you probably can't use MMOs for reliable address space > information. > > /jakob > >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/0630de6d/attachment.html>