[llvm-bugs] [Bug 46626] New: Missed optimization: CorrelatedValuePropagationPass doesn't run by default after inlining

[via llvm-bugs]

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

            Bug ID: 46626
           Summary: Missed optimization: CorrelatedValuePropagationPass
                    doesn't run by default after inlining
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: vlad at tsyrklevich.net
                CC: llvm-bugs at lists.llvm.org

The following reproducer:
$ cat ex.c
static int a;
static int *b(int *c) { return c; }
int foo() {
  if (a == 0)
    a = 2;
  return *b(&a);
}

demonstrates a missed optimization due to not running the
CorrelatedValuePropagationPass after inlining. Compiled to IR, it looks like:
$ clang -S -emit-llvm ex.c -o ex.ll -O2
$ cat ex.ll
...
define i32 @foo() local_unnamed_addr #0 {
  %1 = load i1, i1* @a, align 4
  %2 = select i1 %1, i32 2, i32 0
  br i1 %1, label %4, label %3

3:                                                ; preds = %0
  store i1 true, i1* @a, align 4
  br label %4

4:                                                ; preds = %0, %3
  %5 = phi i32 [ 2, %3 ], [ %2, %0 ]
  ret i32 %5
}
...

By running opt on this clang -O2 output, we get simpler IR:
$ cat ex.ll | opt -S -O2
...
define i32 @foo() local_unnamed_addr #0 {
  %1 = load i1, i1* @a, align 4
  br i1 %1, label %3, label %2

2:                                                ; preds = %0
  store i1 true, i1* @a, align 4
  br label %3

3:                                                ; preds = %2, %0
  ret i32 2
}
...

The difference between the IR for these 2 functions results in the first being
12 bytes larger when compiled on AArch64. The following trivial change 'fixes'
the reproducer given above, but I'm not clear on where in the pipeline the
CorrelatedValuePropagationPass actually belongs. This diff merely shows the
earliest point that pass can be added which fixes the reproducer.
--- a/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
+++ b/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
@@ -668,6 +668,7 @@ void PassManagerBuilder::populateModulePassManager(
   // faster.
   if (RunInliner) {
     MPM.add(createGlobalOptimizerPass());
+    MPM.add(createCorrelatedValuePropagationPass());
     MPM.add(createGlobalDCEPass());
   }

-- 
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/20200708/f65d7fca/attachment.html>