[LLVMbugs] [Bug 19800] New: instcombine creates i96 icmp

[bugzilla-daemon at llvm.org]

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

            Bug ID: 19800
           Summary: instcombine creates i96 icmp
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: dan433584 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For this C++ code:

struct T
{
    unsigned a :4;
    unsigned b :1;
    unsigned c :1;
    unsigned d :10;
    unsigned e :16;
    unsigned f :15;
    unsigned g :1;
    unsigned h :15;
    unsigned i :1;
    unsigned j :15;
    unsigned k :1;
    unsigned l :15;
    unsigned m :1;
};

bool foo(T *p)
{
    return p->a >= 3;
}

clang -O2 -emit-llvm emits LLVM IR that does this:

  %bf.load = load i96* %0, align 4
  %bf.cast = and i96 %bf.load, 15
  %cmp = icmp ugt i96 %bf.cast, 2

even on targets (such as x86-64) which have explicit native integer types in
their datalayout (such as -n8:16:32:64). The i96 icmp is semantically correct,
but surprising, given the general convention that instcombine isn't supposed to
propagate non-legal types through expression trees.

In practice, SelectionDAG codegen optimizes this away by noticing that the
input to the icmp is an and with lots of leading zero bits. However, it seems
awkward to create such illegal comparisons and require SelectionDAG to optimize
them away. It's also problematic for Emscripten, which does not currently use
SelectionDAG, so doesn't currently have code to optimize away the i96
comparison.

Is it intended that instcombine promote comparisons up to illegal types like
this?

-- 
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/20140519/96bdd3f3/attachment.html>