[llvm-bugs] [Bug 47498] New: [MemorySSA] PHI translations leads to wrong defining access for load in loop

[via llvm-bugs]

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

            Bug ID: 47498
           Summary: [MemorySSA] PHI translations leads to wrong defining
                    access for load in loop
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: florian_hahn at apple.com
                CC: llvm-bugs at lists.llvm.org

For the IR below, it seems like PHI translation leads to the wrong defining
access for `%l.1 = load i32, i32* %p.1, align 4`. MemorySSA uses the call to
@init outside the loop as defining access.

But unless I am missing something, I think it should be `; 4 =
MemoryPhi({bb,1},{loop.1.latch,3})`.

Consider the following execution sequence:

1. loop.1.header reads from %tmp[1]...%tmp[11].
2. execute storebb, which writes %tmp[11]
3. goto loop.1.latch
4. execute loop.1.header again, which reads from %tmp[1]...%tmp[11]. That
includes the value stored in %storebb, so the defining access should be `3 =
MemoryPhi...`

https://godbolt.org/z/7srs1s

This leads to DSE+MemorySSA to determine `store i32 10, i32* %p.1, align 4` is
never read and can be removed. I suspect this is causing the following failure:
 http://lab.llvm.org:8011/builders/clang-s390x-linux-lnt/builds/20711


IR:
declare i1 @should_exit(i32) readnone
declare void @init([32 x i32]*)

define i32 @blam(i32 %arg, i32 %arg1)  #0 {
bb:
  %tmp = alloca [32 x i32], align 16
  call void @init([32 x i32]* %tmp)
  br label %loop.1.header

loop.1.header:
  %iv = phi i64 [ 0, %bb ], [ %iv.next, %loop.1.latch ]
  %iv.next = add nuw nsw i64 %iv, 1
  %p.1 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.next
  %l.1 = load i32, i32* %p.1, align 4
  %tmp244 = icmp ult i64 %iv, 10
  br i1 %tmp244, label %loop.1.latch, label %storebb

loop.1.latch:
  %ec = call i1 @should_exit(i32 %l.1)
  br i1 %ec, label %exit, label %loop.1.header

storebb:
  %iv.add2 = add nuw nsw i64 %iv, 2
  %p.2 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.add2
  %l.2 = load i32, i32* %p.2, align 4
  store i32 10, i32* %p.1, align 4
  br label %loop.1.latch

exit:
  ret i32 10
}



opt -analyze -print-memoryssa


define i32 @blam(i32 %arg, i32 %arg1) {
bb:
  %tmp = alloca [32 x i32], align 16
; 1 = MemoryDef(liveOnEntry)
  call void @init([32 x i32]* %tmp)
  br label %loop.1.header

loop.1.header:                                    ; preds = %loop.1.latch, %bb
; 4 = MemoryPhi({bb,1},{loop.1.latch,3})
  %iv = phi i64 [ 0, %bb ], [ %iv.next, %loop.1.latch ]
  %iv.next = add nuw nsw i64 %iv, 1
  %p.1 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.next
; MemoryUse(1) MayAlias
  %l.1 = load i32, i32* %p.1, align 4
  %tmp244 = icmp ult i64 %iv, 10
  br i1 %tmp244, label %loop.1.latch, label %storebb

loop.1.latch:                                     ; preds = %storebb,
%loop.1.header
; 3 = MemoryPhi({loop.1.header,4},{storebb,2})
  %ec = call i1 @should_exit(i32 %l.1)
  br i1 %ec, label %exit, label %loop.1.header

storebb:                                          ; preds = %loop.1.header
  %iv.add2 = add nuw nsw i64 %iv, 2
  %p.2 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.add2
; MemoryUse(1) MayAlias
  %l.2 = load i32, i32* %p.2, align 4
; 2 = MemoryDef(4)
  store i32 10, i32* %p.1, align 4
  br label %loop.1.latch

exit:                                             ; preds = %loop.1.latch
  ret i32 10
}

-- 
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/20200911/a1e8cd36/attachment.html>