[llvm-bugs] [Bug 46717] New: Bug in pass 'ipsccp' on function attribute 'argmemonly'.

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Jul 14 09:20:06 PDT 2020


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

            Bug ID: 46717
           Summary: Bug in pass 'ipsccp' on function attribute
                    'argmemonly'.
           Product: tools
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: opt
          Assignee: unassignedbugs at nondot.org
          Reporter: fangqingdu at gmail.com
                CC: llvm-bugs at lists.llvm.org

When pass 'ipsccp' replaces arguments with global variables, it forgets to
remove the function's 'argmemonly' attribute. Which may cause wrong behavior,
just like following test case(from Alexandre Isoard) shows:

********************************************************
; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s

@g = internal global i32 0

; Function Attrs: argmemonly
define internal void @foo(i32* nonnull dereferenceable(4) %arg, i32 %val) #0 {
entry:
  store i32 %val, i32* %arg
  ret void
}

define i32 @bar(i32 %n) {
entry:
  store i32 1, i32* @g
  br label %loop

loop:                                              ; preds = %bb1, %bb
  %i = phi i32 [ %i.inc, %loop ], [ 0, %entry ]
  %g.val = load i32, i32* @g
  %g.inc = add nuw i32 %g.val, 1
  tail call void @foo(i32* @g, i32 %g.inc)
  %i.inc = add nuw i32 %i, 1
  %cond = icmp eq i32 %i.inc, %n
  br i1 %cond, label %exit, label %loop

exit:                                              ; preds = %bb1
  ret i32 %g.val
}

declare void @llvm.assume(i1)

attributes #0 = { argmemonly }
********************************************************

Before 'ipsccp', function '@foo' is marked with 'argmemonly' attribute. But
after the argument '%arg' is replaced with '@g' by pass 'ipsccp', attribute
'argmemonly' is left there. And due to the 'argmemonly' attribute, pass 'licm'
will think the value of global variable '@g' is not changed (but it is
changed), then hoist the load of the '@g' outside the loop. And cause function
'@bar' return wrong value '1'. But the correct return value should be '%n'.

-- 
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/20200714/83db2b7a/attachment.html>


More information about the llvm-bugs mailing list