[LLVMdev] Loads/Stores and MachineMemOperand

[Justin Holewinski]

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>