[LLVMbugs] [Bug 13412] New: Bad opt from inlining + instsimplify

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13412

             Bug #: 13412
           Summary: Bad opt from inlining + instsimplify
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: paul.robinson at am.sony.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 8930
  --> http://llvm.org/bugs/attachment.cgi?id=8930
One possible patch

The following module compiled at -O2 is incorrectly optimized down to
an unconditional call to fail() and a "ret". It should optimize to
just "ret".
=====================================
$ cat testcase.cpp
void fail(void);

static int* second(int *a, int *b) {
    unsigned long size = b - a;

    if(size >= 2) {
        if(*a == *b)
            return a;
    }
    return b;
}

static bool first(int *a, int *b) {
 return (second(a, b) == b);
}

int main() {
    int i1[2] = {0, 0};
    ((first(i1, i1)) ? (void)0 : fail());

    return 0;
}
$ clang++ -O2 testcase.cpp -S -emit-llvm -o -
; ModuleID = 'testcase.cpp'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @main() uwtable {
cond.end:
  tail call void @_Z4failv()
  ret i32 0
}

declare void @_Z4failv()
$
=====================================

The problem appears to be associated with instruction simplification
during inlining. Because it's an interaction between optimizations,
there are different ways to approach it. I've attached a patch to
SimplifyICmpInst() that seems to work, by eliminating an assumption
that a local object and an argument can't be equal. This assumption
appears not to hold while you're in the middle of inlining.

But, that's not the only possible approach. We could just not do
simplification during function cloning, waiting until things are
self-consistent enough for simplification to work, later on.
Or we could do simplification, but avoid the problematic cases, for
some hopefully sufficient definition of "problematic."

Time to let the experts sort this out...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.