[PATCH] This patch introduces MemorySSA, a virtual SSA form for memory.Details on what it looks like are in MemorySSA.h

[Daniel Berlin]

On Mon, Apr 13, 2015 at 4:41 PM, Philip Reames
<listmail at philipreames.com> wrote:
>
> On 04/13/2015 04:32 PM, Daniel Berlin wrote:
>>>>>
>>>>> ================
>>>>> Comment at: lib/Transforms/Utils/MemorySSA.cpp:942
>>>>> @@ +941,3 @@
>>>>> +  // Don't try to walk past an incomplete phi node during construction
>>>>> +  if (P->getNumIncomingValues() != P->getNumPreds())
>>>>> +    return std::make_pair(P, false);
>>>>> ----------------
>>>>> Er, huh?  How can this happen?  And should it?
>>>>
>>>> So, we use the caching walker during construction to optimize the uses
>>>> on MemoryUse's.
>>>> Depending on where the backedges are, you have no guarantee you won't
>>>> hit a PHI node whose operands are not completely filled in yet,
>>>> because the standard SSA rename algorithm is  top-down, and depth
>>>> first, not breadth first  (so along one branch, you check if your
>>>> successors have phi node, and if so, fill in your open operand.   Then
>>>> you go to your successors, who may want to make queries involving that
>>>> phi node, but not all operands are filled in because the renamer
>>>> hasn't gotten to the *other* branch yet)
>>>>
>>>> Even if we made it breadth first, my gut tells me you can construct a
>>>> CFG with backedges that will end up with not all operands filled in at
>>>> some query point.
>>>
>>> A clear comment in function description which says it has to handle
>>> partially constructed memssa would be very helpful.  I understand why you
>>> want this, but it really makes me wince.
>>>
>>> Any chance the optimization could be done via a lazy fixup after
>>> construction?  Just a though.  (Not as part of this change though!)
>>>
>> So it can be done by fixup, at a cost of walking the memory accesses
>> again.
>> The only way to do it with *lazy* fixup would be to make the walkers
>> modify the IR as they are walking it.
>> Currently they are readonly.
>> Honestly, that idea scares the hell out of me, so i'd rather either
>> accept that we may walk partially constructed phi nodes during
>> construction, or do at as a memory-access walk after construction.
>
> Given your response, I'll discard that random idea.  :)  Dealing with the
> partially constructed graph isn't bad provided we're clear about it.
>

FWIW: It's possible to do it, it just seems very tricky.
For example, what happens if you start walking a backedge in one of
the recursive calls. It seems possible to come up with cases where
you've modified the access lists/etc that one of your calls 20 calls
back up the stack are in the middle of walking. Certainly you can
avoid this. But it requires a *ton* of careful work, and probably not
worth the cost.  Most of the time we spend here is in the AA API, not
in the walking, so i'd rather make this clean and then make it faster
through tricks if we have to.

So on that front, i'm going to change the optimization to happen after
construction, and unless i see at least 20-30% speed difference, going
to keep it there :)

> Philip