[llvm-bugs] [Bug 48676] New: opt -always-inline -instcombine is less powerful than two separate invocations of opt

[via llvm-bugs]

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

            Bug ID: 48676
           Summary: opt -always-inline -instcombine is less powerful than
                    two separate invocations of opt
           Product: new-bugs
           Version: 11.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: info at camilstaps.nl
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

The documentation of the optimizer
(https://llvm.org/docs/CommandGuide/opt.html) states:

> opt provides the ability to run any of LLVM’s optimization or analysis passes in any order. [..] The order in which the options occur on the command line are the order in which they are executed (within pass constraints).

>From this I would expect that these two give the same results:

A. opt -S file.ll -pass-1 -pass-2
B. opt -S file.ll -pass-1 | opt -S -pass-2

(I'm not sure as to what "within pass constraints" refers to, but if they do
not give the same results, I would expect that the first is better. I may of
course be wrong here.)

This is not the case for -always-inline and -instcombine. In the program below,
@f can be optimized to a single ret void, because the store from @pop_store_1
is 'undone' by the 'store undef' from @pop. Invocation B above produces this as
expected.

With invocation A, it seems like the 'store undef' is removed before the
functions are inlined, so that the store from @pop_store_1 remains:

define void @f(i64* %p.0) {
  %p.1.i = getelementptr i64, i64* %p.0, i64 -1
  store i64 1, i64* %p.1.i, align 4
  ret void
}

This is unexpected for me since I ordered -always-inline first and then
-instcombine.

I am working with opt-11, LLVM version 11.0.1, from the Buster repository at
https://apt.llvm.org/.
The full program is:

-------

target triple = "x86_64-pc-linux-gnu"

define private i64* @pop_store_1(i64* %p.0) alwaysinline {
        %p.1 = getelementptr i64, i64* %p.0, i64 -1
        store i64 1, i64* %p.1
        ret i64* %p.1
}

define private i64* @pop(i64* %p.0) alwaysinline {
        store i64 undef, i64* %p.0
        %p.1 = getelementptr i64, i64* %p.0, i64 -1
        ret i64* %p.1
}

define void @f(i64* %p.0) {
        %p.1 = call i64* @pop_store_1(i64* %p.0)
        %p.2 = call i64* @pop(i64* %p.1)
        ret void
}

-- 
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/20210106/e6ea009b/attachment.html>