llvm dev - Dec 2012 - [LLVMdev] Loads/Stores and MachineMemOperand

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>

On Dec 12, 2012, at 5:50 PM, Justin Holewinski <justin.holewinski at
gmail.com> wrote:
> Is this documented somewhere?
It seems that it isn't. It ought to go in the header file.

/jakob

Is there a reason MachineMemOperands are not guaranteed to be persisted in
late optimization passes?  Is there a use-case where they should be
stripped?


On Wed, Dec 12, 2012 at 9:50 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk>wrote:
>
> On Dec 12, 2012, at 5:50 PM, Justin Holewinski <
> justin.holewinski at gmail.com> wrote:
>
> > Is this documented somewhere?
>
> It seems that it isn't. It ought to go in the header file.
>
> /jakob
>
>

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121213/9dbcb888/attachment.html>