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

Akira Hatanaka ahatanak at gmail.com
Mon May 13 17:20:32 PDT 2013


Thanks, I'll commit the patch shortly.


On Mon, May 13, 2013 at 2:52 PM, Nadav Rotem <nrotem at apple.com> wrote:

> The patch LGTM.  The StackColoring patch is still too conservative and I
> am consulting with Jakob and Andy about possible solutions.
>
> On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote:
>
> This is the email I sent last week.
>
> ---------- Forwarded message ----------
> From: Akira Hatanaka <ahatanak at gmail.com>
> Date: Wed, May 8, 2013 at 7:04 PM
> Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing
> mem operands.
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>
>
> 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.
>
>
> <stackcoloring.patch><stackcoloring-test.patch>
> _______________________________________________
>
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130513/e7fc8069/attachment.html>


More information about the llvm-dev mailing list