[LLVMbugs] [Bug 11687] New: jump-threading misses constant GEP

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sun Jan 1 11:47:44 PST 2012


             Bug #: 11687
           Summary: jump-threading misses constant GEP
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is a missed optimization in std::vector _M_insert_aux, the function in
push_back() that doesn't get optimized enough to get inlined. Testcase:

declare i8** @something()

declare void @use(i8)

define void @test(i64 %a) {
  %cmp = icmp eq i64 %a, 0
  br i1 %cmp, label %brtrue, label %brfalse
  %ptr = call i8** @something()
  br label %brtrue
  %phi = phi i8** [ %ptr, %brfalse ], [ null, %entry ]
  %gep = getelementptr inbounds i8** %phi, i64 %a
  %isnull = icmp eq i8** %gep, null
  br i1 %isnull, label %brtrue2, label %brfalse2
  call void @use(i8 1)
  ret void
  call void @use(i8 2)
  ret void

The important missed optimization is the case where %a is zero. Then, %phi is
null, and %gep is "gep inbounds (null, 0)" which is then compared against null
(true) and we should thread the edge directly from %entry to %brtrue2.

This probably belongs in -jump-threading.

There may be a second missed optimization, but I'm not entirely sure. We may be
able to remove the edge from %brtrue to %brtrue2, making it branch directly to
%brfalse2. The matter at hand is whether %gep could be null, given that the GEP
is inbounds and %a is non-zero. Can we have %ptr = inttoptr(10*sizeof(i8**))
and %a = -10 without violating inbounds? I don't think so, in address space
zero. Is the only inbounds gep allowed to return null "gep inbounds (null,
all-zeros)"? Or is even that not legal? If not, then std::vector push_back() is
already being miscompiled...

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.

More information about the llvm-bugs mailing list