[LLVMdev] Loads/Stores and MachineMemOperand

[Justin Holewinski]

Assuming it is not guaranteed that Value* will remain non-NULL due to alias
analysis, the attached patch caches the pointer address space in
MachinePointerInfo so it is still available if Value* is NULL-ed out.

Any issues with this approach?


On Tue, Dec 11, 2012 at 3:02 PM, Justin Holewinski <
justin.holewinski at gmail.com> wrote:

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


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/c29f8943/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Persist-pointer-address-space-in-MachinePointerInfo-.patch
Type: application/octet-stream
Size: 3882 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/c29f8943/attachment.obj>