[llvm-bugs] [Bug 29039] New: Lost opportunity to fold op into phi

[via llvm-bugs]

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

            Bug ID: 29039
           Summary: Lost opportunity to fold op into phi
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: wmi at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

--------  testcase 1.c -----------
int hoo(int p);

int goo(int p) {
  if (__builtin_expect(p, 1)) return 1;
  return hoo(p);
}

long t;
volatile long cond;
void foo(int p) {
  while (cond) {
    t += goo(p);
    if (cond > t)
      t += 2;
  }
  xoo();
}
----------------------------------

llvm generated code for the while loop:
~/workarea/llvm-r278149/dbuild/bin/clang -O2 -S 1.c

.LBB1_1:                                # %entry
                                        # =>This Inner Loop Header: Depth=1
        cmpq    $0, cond(%rip)
        je      .LBB1_6
# BB#2:                                 # %while.body
                                        #   in Loop: Header=BB1_1 Depth=1
        movl    $1, %eax
        testl   %ebx, %ebx
        jne     .LBB1_4
# BB#3:                                 # %if.end.i
                                        #   in Loop: Header=BB1_1 Depth=1
        xorl    %edi, %edi
        callq   hoo
.LBB1_4:                                # %goo.exit
                                        #   in Loop: Header=BB1_1 Depth=1
        cltq     ====> The cltq can be hoisted to BB#3. 
        addq    t(%rip), %rax
        movq    %rax, t(%rip)
        movq    cond(%rip), %rcx
        cmpq    %rax, %rcx
        jle     .LBB1_1

It is better to generate cltq immediately behind "callq hoo" since the def of
eax in BB#2 is $1 and cltq is of no use.

This could have been done by InstCombiner::FoldOpIntoPhi. However, because
r221187 is too conservative, any such folding opportunity in a loop is lost.

I am thinking about how to replace r221187 with something less restricted. An
idea is to only fold op from more frequently executed BB to the less, so no
infinite combine will be introduced. However, we don't have BFI in instcombine.
I am not sure whether it is intentional. Maybe the job of instcombine is to do
canonicalization so it doesn't want to depend on BFI?

-- 
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/20160818/a34b2c1a/attachment.html>