[llvm-bugs] [Bug 49335] New: libcall simplification not reliably being applied by early instcombine

[via llvm-bugs]

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

            Bug ID: 49335
           Summary: libcall simplification not reliably being applied by
                    early instcombine
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: llvm-bugs at lists.llvm.org

Testcase (https://godbolt.org/z/s3cxzv):

#include <llvm/ADT/StringRef.h>

bool f(llvm::StringRef s) {
    return s.size() > 1 && s[0] == '0';
}
bool g(llvm::StringRef s) {
    return s.startswith("0") && s != "0";
}


I would expect `f` and `g` to produce equivalent code, but they don't. `f`
produces a branch on size followed by a comparison of s[0]:

  %3 = icmp ugt i64 %1, 1
  br i1 %3, label %4, label %7

4:                                                ; preds = %2
  %5 = load i8, i8* %0, align 1, !tbaa !2
  %6 = icmp eq i8 %5, 48
  br label %7

7:                                                ; preds = %4, %2
  %8 = phi i1 [ false, %2 ], [ %6, %4 ]
  ret i1 %8

That seems fine. But `g` compares `s[0]` against `'0'` twice:

  %3 = icmp eq i64 %1, 0
  br i1 %3, label %12, label %4

4:                                                ; preds = %2
  %5 = load i8, i8* %0, align 1
  %6 = icmp eq i8 %5, 48
  br i1 %6, label %7, label %12

7:                                                ; preds = %4
  %8 = icmp eq i64 %1, 1
  br i1 %8, label %9, label %12

9:                                                ; preds = %7
  %10 = load i8, i8* %0, align 1
  %11 = icmp ne i8 %10, 48
  br label %12

12:                                               ; preds = %2, %9, %7, %4
  %13 = phi i1 [ false, %4 ], [ true, %7 ], [ %11, %9 ], [ false, %2 ]
  ret i1 %13

We don't seem to notice that %10 is identical to %5.


It looks like (https://godbolt.org/z/MaPvMY) the second load is part of a call
to @bcmp until too late. Early InstCombinePasses leave the @bcmp call alone,
and it's only transformed to a load-and-compare by the InstCombinePass that
runs immediately after the BDCE pass, but we don't do any more GVN after that
point.

It's not clear to me why the pre-GVN InstCombine doesn't fire on the @bcmp
call:

  %10 = tail call i32 @bcmp(i8* nonnull %0, i8* getelementptr inbounds ([2 x
i8], [2 x i8]* @.str, i64 0, i64 0), i64 %1) #7

... but the post-GVN InstCombine does fire on an apparently-identical call. (In
fact, the entire function appears to be identical according to
-print-after-all, but InstCombine does different things?)

-- 
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/20210223/cee78d71/attachment.html>