[llvm-bugs] [Bug 46447] New: [WebAssembly] Bad switch codegen for i64 on wasm-opt

[via llvm-bugs]

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

            Bug ID: 46447
           Summary: [WebAssembly] Bad switch codegen for i64 on wasm-opt
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: alonzakai at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23647
  --> https://bugs.llvm.org/attachment.cgi?id=23647&action=edit
reduced testcase

This issue was initially reported as
https://github.com/WebAssembly/binaryen/pull/2925

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.

-- 
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/20200625/3020d97c/attachment.html>