[llvm-bugs] [Bug 36529] New: MemorySSA doesn't properly invalidate def-def cache entries

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36529

            Bug ID: 36529
           Summary: MemorySSA doesn't properly invalidate def-def cache
                    entries
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: george.burgess.iv at gmail.com
                CC: llvm-bugs at lists.llvm.org

Consider the following code:

define void @foo(i8* %a, i8* %b) {
  ; 1 = MemoryDef(liveOnEntry)
  store i8 0, i8* %a
  ; 2 = MemoryDef(1)
  store i8 0, i8* %b
  ; 3 = MemoryDef(2)
  store i8 0, i8* %a
  ; 4 = MemoryDef(3)
  store i8 0, i8* %b
}

If we use the caching MSSA walker to get the clobbering access of `3` (which is
`1`), we'll cache that result in `3`. If `1` and its corresponding store are
removed from the function -- it's trivially dead, after all -- the cache for
`3` will still be seen as valid, and will still return `1`'s old pointer.

Were we to similarly remove `2`, however, the cache for `3` *would* be properly
invalidated. This is because (I assume) we use "do we have the same store above
us" as a signal for whether the current store has been moved.

This issue does not apply for MemoryUses, since we use operands to do
bookkeeping with those.

The simplest way to fix this seems to be adding an 'optimized' operand to
MemoryDefs, rather than storing 'optimized' as a regular pointer field. Doing
so doesn't loudly break any tests, though I'm unsure if it'll cause functional
changes for existing passes (since with this approach, walking an operands list
for a def now requires extra checks if you don't want to visit every def
twice...). I also don't know offhand how {un,}happy the updater will be with
this. I'll see what I can find out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180226/24d0b9b4/attachment.html>