[llvm-bugs] [Bug 35211] New: Incorrect store to load forwarding for noalias pointer across return_twice functions

[via llvm-bugs]

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

            Bug ID: 35211
           Summary: Incorrect store to load forwarding for noalias pointer
                    across return_twice functions
           Product: libraries
           Version: 5.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: yyc1992 at gmail.com
                CC: llvm-bugs at lists.llvm.org

The IR repro independent of C code is,

```
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: noinline nounwind sspstrong uwtable
define i32 @f(i32) #0 {
  %2 = call noalias i32* @alloc(i64 4) #1
  store i32 %0, i32* %2, align 4
  %3 = call i32 @enter() #2
  %4 = icmp eq i32 %3, 0
  br i1 %4, label %5, label %6

; <label>:5:                                      ; preds = %1
  store i32 1, i32* %2, align 4
  call void @throw() #3
  unreachable

; <label>:6:                                      ; preds = %1
  %7 = load i32, i32* %2, align 4
  ret i32 %7
}

; Function Attrs: nounwind
declare noalias i32* @alloc(i64) #1

; Function Attrs: nounwind returns_twice
declare i32 @enter() #2

; Function Attrs: noreturn nounwind
declare void @throw() #3

attributes #0 = { noinline nounwind sspstrong uwtable }
attributes #1 = { nounwind }
attributes #2 = { nounwind returns_twice }
attributes #3 = { noreturn nounwind }
```

This is optimized by GVN to

```
define i32 @f(i32) #0 {
  %2 = call noalias i32* @alloc(i64 4) #1
  store i32 %0, i32* %2, align 4
  %3 = call i32 @enter() #2
  %4 = icmp eq i32 %3, 0
  br i1 %4, label %5, label %6

; <label>:5:                                      ; preds = %1
  store i32 1, i32* %2, align 4
  call void @throw() #3
  unreachable

; <label>:6:                                      ; preds = %1
  ret i32 %0
}
```

Which is wrong since the `enter` may return a second time after the store of
`1`.

The issue is obviously fixed if the store and load are marked as volatile but
those should only be needed for stack addresses.

A C repro is,

```
#include <stdlib.h>
#include <setjmp.h>

int f(int b)
{
    jmp_buf buf;
    int *p = (int*)malloc(sizeof(int));
    *p = b;
    if (setjmp(buf) == 0) {
        *p = 1;
        longjmp(buf, 1);
    }
    int c = *p;
    free(p);
    return c;
}
```

Which is optimized by `clang -O3` to
```
define i32 @f(i32) local_unnamed_addr #0 {
  %2 = alloca [1 x %struct.__jmp_buf_tag], align 16
  %3 = bitcast [1 x %struct.__jmp_buf_tag]* %2 to i8*
  call void @llvm.lifetime.start.p0i8(i64 200, i8* nonnull %3) #4
  %4 = getelementptr inbounds [1 x %struct.__jmp_buf_tag], [1 x
%struct.__jmp_buf_tag]* %2, i64 0, i64 0
  %5 = call i32 @_setjmp(%struct.__jmp_buf_tag* nonnull %4) #5
  %6 = icmp eq i32 %5, 0
  br i1 %6, label %7, label %8

; <label>:7:                                      ; preds = %1
  call void @longjmp(%struct.__jmp_buf_tag* nonnull %4, i32 1) #6
  unreachable

; <label>:8:                                      ; preds = %1
  call void @llvm.lifetime.end.p0i8(i64 200, i8* nonnull %3) #4
  ret i32 %0
}
```

In this case, I believe it is clear from the C spec that the optimization is
illegal, without assuming any llvm specific semantic of `noalias` which the
LLVM IR case above relies on.

This is similar to https://bugs.llvm.org/show_bug.cgi?id=21183 but is an IR
level bug and not limited to a particular backend.

-- 
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/20171106/4786c273/attachment.html>