[llvm-dev] [LICM][MemorySSA] Converting LICM pass to use MemorySSA to avoid AliasSet collapse issue

[Daniel Berlin via llvm-dev]

On Mon, Apr 11, 2016 at 12:03 PM, Geoff Berry <gberry at codeaurora.org> wrote:

> Hi All,
>
>
>
> I’m looking into converting LICM to use MemorySSA instead of AliasSets to
> determine when it is safe to hoist/sink/promote loads and stores to get
> around the issue of alias set collapse (see discussion [1]).
>

Thank you


> I have a prototype implementation, but have run into two issues that I
> could use input from the designers of MemorySSA to resolve:
>
> 1)      Is MemorySSA intended to be maintained across passes?  More
> specifically how is it intended to interact with the Pass Manager?  In my
> current prototype I’m just building it at the start of LICM.
>
I am working on it, it will be preserved/destroyed like any analysis pass.


> 2)      What is the intended method for dealing with changes to the
> function that invalidate the MemorySSA form?  I see that there is a way to
> remove nodes from the MemorySSA graph, but for other transformations (e.g.
> hoisting a load) am I supposed to just update the MemorySSA graph myself?
>

For hoisting loads, i have an API that will work abotu to be under review
over here:
http://reviews.llvm.org/D18090
a load hoist will look something like this to update:

  // We also hoist operands of loads using this function, so check to see if
  // this is really a memory access before we try to update MemorySSA for
it.
  MemoryAccess *HoistCandAccess = MSSA->getMemoryAccess(HoistCand);
  if (HoistCandAccess) {
    MemoryUseOrDef *MUD = cast<MemoryUseOrDef>(HoistCandAccess);
    // What is happening here is that we are creating the hoisted access
    // and destroying the old accesses.
    MSSA->createMemoryAccess(HoistedInst, MUD->getDefiningAccess(), BB,
                             MemorySSA::End);
    MSSA->removeMemoryAccess(HoistCandAccess);
    MSSA->removeMemoryAccess(MSSA->getMemoryAccess(ElseInst));
  }


(this is "create a new access with this memorydef as it's definition, kill
these two old loads").


A store sink is slightly harder, but it will be similar.

Comments welcome!



>
>
>
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2015-April/084881.html
>
>
>
> --
>
> Geoff Berry
>
> Employee of Qualcomm Innovation Center, Inc.
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160411/9d97c1b1/attachment.html>