[LLVMbugs] [Bug 16426] New: Agressively merge BBs of predict-taken paths

[bugzilla-daemon at llvm.org]

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

            Bug ID: 16426
           Summary: Agressively merge BBs of predict-taken paths
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: nunoplopes at sapo.pt
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I think LLVM should be more agressive in merging BBs of predict-taken paths.

E.g.:
size_t safe_address(size_t nmemb, size_t size, size_t offset) {
  unsigned long res;
  if (__builtin_expect(
       __builtin_expect(__builtin_umul_overflow(nmemb, size, &res), 0) ||
       __builtin_expect( __builtin_uadd_overflow(res, offset, &res), 0), 0)) {
    return 0;
  }
  return res;
}

(multiple __builtin_expect because of another unrelated bug).


This code compiles to:

define i32 @safe_address(i32 %nmemb, i32 %size, i32 %offset) {
entry:
  %0 = tail call { i32, i1 } @llvm.umul.with.overflow.i32(i32 %nmemb, i32
%size)
  %1 = extractvalue { i32, i1 } %0, 1
  br i1 %1, label %lor.end, label %lor.rhs, !prof !0

lor.rhs:                                          ; preds = %entry
  %2 = extractvalue { i32, i1 } %0, 0
  %3 = tail call { i32, i1 } @llvm.uadd.with.overflow.i32(i32 %2, i32 %offset)
  %4 = extractvalue { i32, i1 } %3, 1
  %5 = extractvalue { i32, i1 } %3, 0
  %phitmp = select i1 %4, i32 0, i32 %5
  br label %lor.end

lor.end:                                          ; preds = %lor.rhs, %entry
  %6 = phi i32 [ 0, %entry ], [ %phitmp, %lor.rhs ]
  ret i32 %6
}

!0 = metadata !{metadata !"branch_weights", i32 4, i32 64}

declare { i32, i1 } @llvm.umul.with.overflow.i32(i32, i32) #1
declare { i32, i1 } @llvm.uadd.with.overflow.i32(i32, i32) #1
attributes #1 = { nounwind readnone }


Since we know that the branch to 'lor.rhs' is assumed to be taken and that
there's no instruction with side-effects in that BB, we should merge the
'entry' and 'lor.rhs' BBs.  Merging BBs helps later passes, like instruction
selection.

-- 
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/20130623/cd6c8647/attachment.html>