<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - opt -always-inline -instcombine is less powerful than two separate invocations of opt"
href="https://bugs.llvm.org/show_bug.cgi?id=48676">48676</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>opt -always-inline -instcombine is less powerful than two separate invocations of opt
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>11.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>info@camilstaps.nl
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>The documentation of the optimizer
(<a href="https://llvm.org/docs/CommandGuide/opt.html">https://llvm.org/docs/CommandGuide/opt.html</a>) states:
<span class="quote">> 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).</span >
>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
<a href="https://apt.llvm.org/">https://apt.llvm.org/</a>.
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
}</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>