[llvm-bugs] [Bug 47243] New: Instcombine drops range information when combining inttoptr with load

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Aug 19 14:58:09 PDT 2020


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

            Bug ID: 47243
           Summary: Instcombine drops range information when combining
                    inttoptr with load
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: quentin.colombet at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23865
  --> https://bugs.llvm.org/attachment.cgi?id=23865&action=edit
Reproducer

When instcombine replaces inttoptr(load intTy) to (load ptrTy) it drops the
range information attached to the load.
More precisely, it replaces the range information with an inferior metadata.

The problem may lay into what the range information can represent, but we
should fix that one way or another as this may result in suboptimal code.

* Example *

Consider the following snippet:
```
define float* @test5_range(i64* %ptr) {
entry:
  %val = load i64, i64* %ptr, !range !{i64 64, i64 65536}
  %valptr = inttoptr i64 %val to float*
  ret float* %valptr
}
```

The returned pointer is known to be between address 64 and address 65536.

After instcombine however, this information is lost and instead we have a less
rich information that the pointer is non-null:
```
define float* @test5_range(i64* %ptr) {
entry:
  %0 = bitcast i64* %ptr to float**
  %val1 = load float*, float** %0, align 4, !nonnull !0
  ret float* %val1
}
```

* To Reproduce *

opt -S  -instcombine ~/Downloads/instcombine_range.ll  -o -

-- 
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/20200819/21a8fdf4/attachment-0001.html>


More information about the llvm-bugs mailing list