[llvm-dev] [MemorySSA] Potential bug in MemoryUse defining access calculation

[Daniel Berlin via llvm-dev]

This is definitely a caching bug related to this code:
   1038    // Don't try to optimize this phi again if we've already tried
to do so.
   1039    if (!Q.Visited.insert(PHIPair).second) {
   1040      ModifyingAccess = CurrAccess;
   1041      break;
   1042    }


We don't differentiate elsewhere between having stopped at a phi because we
were path walking and discovered that path has no conflicts, and having
stopped at a phi because that was the clobbering access.

Because of this, we cache the result as if it was a clobbering access, when
it really means "you can ignore this path".

The logic in the code that handles the former case only exists after the
cache lookups, and so the first use properly detects that it can ignore
this phi, and the second use , which just hits the cache, cannot.



On Mon, Jun 27, 2016 at 10:27 AM, Geoff Berry <gberry at codeaurora.org> wrote:

> Hey All,
>
> I've come across what I believe to be a bug in MemorySSA. George, I wasn't
> sure if this was a known issue that you'll be addressing in your upcoming
> walker caching changes or not, so I haven't investigated it very much.  The
> test case is attached. The bug is that the defining access for the second
> load is set to the loop MemoryPhi node instead of being liveOnEntry as it
> should be as I understand things.
>
> --
> 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/20160627/c053964f/attachment.html>