<div dir="ltr">This is the email I sent last week.<br><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Akira Hatanaka</b> <span dir="ltr"><<a href="mailto:ahatanak@gmail.com">ahatanak@gmail.com</a>></span><br>
Date: Wed, May 8, 2013 at 7:04 PM<br>Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands.<br>To: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
<br><br><div dir="ltr"><div>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:<br>

<br>// Update the MachineMemOperand to use the new alloca.<br> 522       for (MachineInstr::mmo_iterator MM = I->memoperands_begin(),<br>....<br>         // Climb up and find the original alloca.<br> 532         V = GetUnderlyingObject(V);<br>

 533         // If we did not find one, or if the one that we found is not in our<br> 534         // map, then move on.<br> 535         if (!V || !isa<AllocaInst>(V)) {<br> 536           // Clear mem operand since we don't know for sure that it doesn't<br>

 537           // alias a merged alloca.<br> 538           MMO->setValue(0);<br> 539           continue;<br> 540         }<br><br>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).<br>

<br></div><div>Please review.<br><br>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.<br>
<br></div></div>
</div><br></div></div>