<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 - incorrect (?) transformation around icmp"
href="https://bugs.llvm.org/show_bug.cgi?id=46380">46380</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>incorrect (?) transformation around icmp
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</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>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Scalar Optimizations
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>post+llvm@ralfj.de
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>(Bugzilla made me pick a component, so I made a wild guess. I do not have the
slightest idea which of these internal LLVM components is responsible here.
Would be nice if I could select "unknown"...)
In <a class="bz_bug_link
bz_status_NEW "
title="NEW - InstCombine cannot blindly assume that inttoptr(ptrtoint x) -> x"
href="show_bug.cgi?id=34548#c99">https://bugs.llvm.org/show_bug.cgi?id=34548#c99</a>, Eli Friedman wrote
<span class="quote">> icmp is defined to just take the raw pointer bits as an integer.
> If some transform isn't consistent with this, please file a bug.</span >
I think Juneyoung found a transformation that is indeed not consistent with
this, which I adjusted as follows (<a href="https://godbolt.org/z/XYQ7Vx">https://godbolt.org/z/XYQ7Vx</a>):
define i1 @compare(i32* %p, i32* %q) {
%c = icmp eq i32* %p, %q
ret i1 %c
}
define void @src() {
%p = alloca i32
%q = alloca i32
call void @llvm.lifetime.start.p0i32(i64 1, i32* %p)
call void @llvm.lifetime.end.p0i32(i64 1, i32* %p)
call void @llvm.lifetime.start.p0i32(i64 1, i32* %q)
%c = call i1 @compare(i32* %p, i32* %q)
br i1 %c, label %A, label %B
A: ; compare() == true
call void @f(i1 true)
%c2 = icmp eq i32* %p, %q
call void @f(i1 %c2)
br label %EXIT
B: ; compare() == false
call void @f(i1 false)
%c3 = icmp eq i32* %p, %q
call void @f(i1 %c3)
br label %EXIT
EXIT:
call void @llvm.lifetime.end.p0i32(i64 1, i32* %q)
ret void
}
The function "src" compares "p" and "q" twice, once inside "compare". It calls
"f" twice with the two results of the comparison. The first comparison is
passed via indirect information flow, i.e., the equivalent of "if p == q {
f(true) } else { f(false) }" in Rust. "p" and "q" could be equal or not, so
this function has two possible executions: either "f" gets called twice with
"true" as argument, or it gets called twice with "false" as argument.
The transformed program (with "opt -instsimplify") is
define i1 @compare(i32* %p, i32* %q) {
%c = icmp eq i32* %p, %q
ret i1 %c
}
define void @src() {
%p = alloca i32, align 4
%q = alloca i32, align 4
call void @llvm.lifetime.start.p0i32(i64 1, i32* %p)
call void @llvm.lifetime.end.p0i32(i64 1, i32* %p)
call void @llvm.lifetime.start.p0i32(i64 1, i32* %q)
%c = call i1 @compare(i32* %p, i32* %q)
br i1 %c, label %A, label %B
A: ; preds = %0
call void @f(i1 true)
call void @f(i1 false)
br label %EXIT
B: ; preds = %0
call void @f(i1 false)
call void @f(i1 false)
br label %EXIT
EXIT: ; preds = %B, %A
call void @llvm.lifetime.end.p0i32(i64 1, i32* %q)
ret void
}
Notice how in block A, "f" gets called with two *different* values, which
should be impossible because the original program only calls f with two times
the same value.</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>