[llvm-bugs] [Bug 44423] New: LLVM 10 regression in gep inbounds of zero-offset gep

[via llvm-bugs]

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

            Bug ID: 44423
           Summary: LLVM 10 regression in gep inbounds of zero-offset gep
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: nikita.ppv at gmail.com
                CC: llvm-bugs at lists.llvm.org

define i32* @test([0 x i32]* %base, i64 %idx) {
  %base2 = bitcast [0 x i32]* %base to i32*
  ;%base2 = getelementptr [0 x i32], [0 x i32]* %base, i64 0, i64 0
  %ptr = getelementptr inbounds i32, i32* %base2, i64 %idx
  ret i32* %ptr
}

opt -instcombine now gives:

define i32* @test([0 x i32]* %base, i64 %idx) {
  %ptr = getelementptr [0 x i32], [0 x i32]* %base, i64 0, i64 %idx
  ret i32* %ptr
}

while previously:

define i32* @test([0 x i32]* %base, i64 %idx) {
  %ptr = getelementptr inbounds [0 x i32], [0 x i32]* %base, i64 0, i64 %idx
  ret i32* %ptr
}

This is because bitcasts are now converted to gep rather than gep inbounds, and
we drop the inbounds when combining both geps.

I believe that in this case the inbounds should be preserved, as the base gep
is zero-offset, so it has no impact on the overall inbounds-ness of the
operation.

-- 
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/20200101/68e0ed1d/attachment.html>