[LLVMdev] [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands.

[Akira Hatanaka]

The following code snippet taken from StackColoring::remapInstructions
clears a mem operand if it can't guarantee whether the memoperand's
underlying value aliases with the merged allocas:

// Update the MachineMemOperand to use the new alloca.
 522       for (MachineInstr::mmo_iterator MM = I->memoperands_begin(),
....
         // Climb up and find the original alloca.
 532         V = GetUnderlyingObject(V);
 533         // If we did not find one, or if the one that we found is not
in our
 534         // map, then move on.
 535         if (!V || !isa<AllocaInst>(V)) {
 536           // Clear mem operand since we don't know for sure that it
doesn't
 537           // alias a merged alloca.
 538           MMO->setValue(0);
 539           continue;
 540         }

The attached patch makes the code above less conservative. It avoids
clearing a mem operand if its underlying value is a PseudoSourceValue and
PseudoSourceValue::isConstant returns true. This enables MachineLICM to
hoist loads from GOT out of a loop (see test case in
stackcoloring-test.patch).

Please review.

Question: Why does it need to clear a mem operand if the underlying object
is not an AllocaInst? I am not sure if I understand the reason for this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/1321c612/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stackcoloring.patch
Type: application/octet-stream
Size: 917 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/1321c612/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stackcoloring-test.patch
Type: application/octet-stream
Size: 1427 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/1321c612/attachment-0001.obj>