<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 - [WebAssembly] Bad switch codegen for i64 on wasm-opt"
href="https://bugs.llvm.org/show_bug.cgi?id=46447">46447</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[WebAssembly] Bad switch codegen for i64 on wasm-opt
</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>Backend: WebAssembly
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>alonzakai@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=23647" name="attach_23647" title="reduced testcase">attachment 23647</a> <a href="attachment.cgi?id=23647&action=edit" title="reduced testcase">[details]</a></span>
reduced testcase
This issue was initially reported as
<a href="https://github.com/WebAssembly/binaryen/pull/2925">https://github.com/WebAssembly/binaryen/pull/2925</a>
A reduced testcase is given here - the function where the bug happens is
reduced as much as possible, and you can ignore all the rest of the file.
STR:
1. Copy that OptimizeInstructions into a binaryen checkout, overwriting the
normal file.
2. emcc src/passes/OptimizeInstructions.cpp -O2 -c -o a.o -Isrc/
3. wasm2wat --enable-all a.o > a.wat
The bug can then be seen in that wat file directly.
The bug is in this short function:
===
Expression* optimizeWithConstantOnRight(Binary* binary) {
auto* right = binary->right->cast<Const>();
auto constRight = right->value.getInteger();
if (constRight == 1LL) {
return right;
}
// operations on all 1s
//std::cout << constRight << '\n'; // this line fixes it..?!
if (constRight == -1LL) {
if (binary->op == Abstract::getBinary(Type::i64, Abstract::LeU)) {
// (unsigned)x <= -1 ==> 1
right->value = Literal::makeFromInt32(1, Type::i32);
return right;
}
}
// TODO: v128 not implemented yet
return nullptr;
}
===
Note how we get that constRight value, then compare that i64 to 1, and then to
-1. So we have three values we care about, -1, 1, and anything else. The
optimizer turns that into a switch:
===
(func
$_ZN4wasm20OptimizeInstructions27optimizeWithConstantOnRightEPNS_6BinaryE (type
5) (param i32 i32) (result i32)
(local i32 i32 i32 i32)
..
block ;; label = @1
..
block ;; label = @2
block ;; label = @3
block ;; label = @4
local.get 3
i32.const 8
i32.add
local.tee 5
call 25 ;; _ZNK4wasm7Literal10getIntegerEv
i64.const 1
i64.add
i32.wrap_i64
br_table 0 (;@4;) 2 (;@2;) 1 (;@3;) 2 (;@2;)
end
===
You can see the getInteger call there. We then add 1 to it. Then we wrap to 32
bits, and do a switch with values for 0, 1, 2.
The problem is that the br_table does the same for an i64 of -1 and of
4294967295 (0xffffffff). In the former case adding 1 means we have 0, and then
reach the first item in the br_table. In the latter case adding 1 means we have
0x100000000 which after wrapping is once again 0.
Note the line with "this line fixes it..?!" - if that is uncommented, the bug
vanishes, as putting that in the middle there avoids LLVM emitting a br_table.
So the bug seems related to br_tables somehow.</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>