[WASM] "signext" attribute leads miscompilation

[doit-man]

define i32 @foo(i1 signext noundef %cond, i32 noundef %y) {
  %e = zext i1 %cond to i32
  %r = sub i32 %y, %e
  ret i32 %r
}

Compiling with

llc --march=wasm32 -filetype=obj {ll} -o {obj}

wasm-ld --no-entry --export-all --allow-undefined {obj} -o {wasm}

(module
  (type (;0;) (func))
  (type (;1;) (func (param i32 i32) (result i32)))
  (func $__wasm_call_ctors (type 0))
  (func $foo (type 1) (param i32 i32) (result i32)
    local.get 1
    local.get 0
    i32.add)
  (memory (;0;) 2)
  (global $__stack_pointer (mut i32) (i32.const 66560))
  (global (;1;) i32 (i32.const 1024))
  (global (;2;) i32 (i32.const 1024))
  (global (;3;) i32 (i32.const 1024))
  (global (;4;) i32 (i32.const 66560))
  (global (;5;) i32 (i32.const 1024))
  (global (;6;) i32 (i32.const 66560))
  (global (;7;) i32 (i32.const 131072))
  (global (;8;) i32 (i32.const 0))
  (global (;9;) i32 (i32.const 1))
  (export "memory" (memory 0))
  (export "__wasm_call_ctors" (func $__wasm_call_ctors))
  (export "foo" (func $foo))
  (export "__dso_handle" (global 1))
  (export "__data_end" (global 2))
  (export "__stack_low" (global 3))
  (export "__stack_high" (global 4))
  (export "__global_base" (global 5))
  (export "__heap_base" (global 6))
  (export "__heap_end" (global 7))
  (export "__memory_base" (global 8))
  (export "__table_base" (global 9)))

The first argument of the function should subtract the second argument, but in WASM, it appears to be performing addition.
signext attribute leads this miscompilation. without signext compilation is correct.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

[efriedma-quic]

As far as I can tell, this isn't a miscompile; do you have a complete example that breaks?

[doit-man]

Sorry, I fix wasm code. If first argument (%cond) is 1, second argument is 0 , %cond is zero-extended to still 1 and result is 0 - 1 = -1 in llvm. But in wasm, first argument just added to second argument, so the result is 0 + 1 = 1

This is the proof of concept in llvm

; ModuleID = 'poc.c'
source_filename = "poc.c"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

@.str = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1

; Function Attrs: noinline nounwind optnone uwtable

define i32 @src(i1 signext noundef %cond, i32 noundef %y) {
  %e = zext i1 %cond to i32
  %r = sub i32 %y, %e
  ret i32 %r
}

define dso_local i32 @main() #0 {
start:
    %0 = call i32 @src(i1 1, i32 0)
    %1 = call i32 (i8*, ...) @printf(i8* noundef getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 noundef %0)
    ret i32 %0
  ret i32 0
}

declare i32 @printf(i8* noundef, ...) #1

attributes #0 = { noinline nounwind optnone uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #1 = { "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }

!llvm.module.flags = !{!0, !1, !2, !3, !4}
!llvm.ident = !{!5}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 7, !"PIC Level", i32 2}
!2 = !{i32 7, !"PIE Level", i32 2}
!3 = !{i32 7, !"uwtable", i32 1}
!4 = !{i32 7, !"frame-pointer", i32 2}
!5 = !{!"Ubuntu clang version 17.0.0-1ubuntu1"}

This is the proof of concept executing wasm binary in js.

function foo() {
const buf = read('/home/doitman/project/temp/jstv-experiment/temp/poc.wasm', 'binary');
let res = WebAssembly.instantiate(buf).then((src) => console.log(src.instance.exports.src(1,0)));

return res;
}
foo();%

Each result is as follow.

Also, when run this wasm binary in wasmi, it also return 0 + 1 = 1

[efriedma-quic]

Oh, I see. The issue is that the callee assumes the i1 is sign-extended, so the value passed is actually -1. In which case just adding the values is correct. The bug is that the caller isn't passing it that way.

If you explicitly mark the argument "signext", it looks like it gets passed correctly. So I guess the wasm target is checking for the attribute in some unusual way; x86 isn't sensitive the same way.

[doit-man]

Thank you for your answer. I have reviewed some past issues and gained an understanding of the current situation.
 
 AssemblyScript/assemblyscript#38
rustwasm/team#88

My problem is as follows.
When trying to import a function from a wasm binary in specific environment such as javascript , the wasm binary does not indicate that the parameter should be sign-extended.
In the above situation, it is not easy to know that I have to passed -1 (1 sign extended) to do the same movement, but I wonder if this is solely the responsibility of the programmer.

[efriedma-quic]

Sorry, I don't know anything about ABIs on wasm specifically; maybe someone else has some input.

[doit-man]

I think this is a miscompiled bug.

define i32 @foo(i1 signext noundef %cond, i32 noundef %y) {
  %e = zext i1 %cond to i32
  %r = sub i32 %y, %e
  ret i32 %r
}

declare i32 @foo(i1 signext noundef, i32 noundef)

define i32 @main() #0 {
start:
    %0 = call i32 @foo(i1 1, i32 0)
    ret i32 %0
}

compiling with below options.

llc --march=wasm32 --filetype=obj temp/foo.ll -o temp/foo.o
llc --march=wasm32 --filetype=obj -O0 temp/main.ll -o temp/main.o

and linking these two object files to one binary

wasm-ld --no-entry --export-all --allow-undefined temp/foo.o temp/main.o -o temp/poc.wasm

below is the result wasm binary.

(module
  (type (;0;) (func))
  (type (;1;) (func (param i32 i32) (result i32)))
  (type (;2;) (func (result i32)))
  (func $__wasm_call_ctors (type 0))
  (func $foo (type 1) (param i32 i32) (result i32)
    local.get 1
    local.get 0
    i32.add)
  (func $__original_main (type 2) (result i32)
    (local i32 i32 i32)
    i32.const 1
    local.set 0
    i32.const 0
    local.set 1
    local.get 0
    local.get 1
    call $foo
    local.set 2
    local.get 2
    return)
  (func $main (type 1) (param i32 i32) (result i32)
    (local i32)
    call $__original_main
    local.set 2
    local.get 2
    return)
  (memory (;0;) 2)
  (global $__stack_pointer (mut i32) (i32.const 66560))
  (global (;1;) i32 (i32.const 1024))
  (global (;2;) i32 (i32.const 1024))
  (global (;3;) i32 (i32.const 1024))
  (global (;4;) i32 (i32.const 66560))
  (global (;5;) i32 (i32.const 1024))
  (global (;6;) i32 (i32.const 66560))
  (global (;7;) i32 (i32.const 131072))
  (global (;8;) i32 (i32.const 0))
  (global (;9;) i32 (i32.const 1))
  (export "memory" (memory 0))
  (export "__wasm_call_ctors" (func $__wasm_call_ctors))
  (export "foo" (func $foo))
  (export "__original_main" (func $__original_main))
  (export "main" (func $main))
  (export "__dso_handle" (global 1))
  (export "__data_end" (global 2))
  (export "__stack_low" (global 3))
  (export "__stack_high" (global 4))
  (export "__global_base" (global 5))
  (export "__heap_base" (global 6))
  (export "__heap_end" (global 7))
  (export "__memory_base" (global 8))
  (export "__table_base" (global 9)))

expected result of the function foo (in llvm ir) is 0 -1 = -1 .
but the result is 0 + 1 = 1.

when two different optimization options are given to each functions, it leads to different result.
I think this has some issues.

Can anyone help me with this issue?

[aqjune]

To summarize, compiling the @foo and @main functions with different optimization flags and linking them results in presenting incorrect behavior (which is printing 1).
Interestingly, this behavior does not appear if the functions are compiled with a same optimization flag.

I think ABI must not be affected by the optimization flag (either -O0 or -O1), whatever the ABI of WASM is.

[doit-man]

We are discussing this issue in https://discourse.llvm.org/t/there-seems-to-be-a-issue-with-optimization-to-wasm/71697 now.

[danilaml]

@efriedma-quic I don't think the signext on a call is relevant since you can see the difference in codegen even when considering single function in isolation and even on x86:

define i32 @foo(i1 signext noundef %cond, i32 noundef %y) {
  %e = zext i1 %cond to i32
  %r = sub i32 %y, %e
  ret i32 %r
}

https://godbolt.org/z/f6dq4oz7b

If you enable debug output, you'll see that zero_extend or and val, 1 disappear during dag isel, which might indicate that there is a faulty transformation/analysis that assumes that zext i1 (i1 signext argument) is a noop.

[aqjune]

Hello all, would there be someone to invite who might be also related to this topic? Would like to make some progress in this issue.

[efriedma-quic]

Looked a bit more; my understanding of the issues here is the following:

• The normal wasm ABI zero-extends booleans.
• If you mark a boolean "signext" in LLVM IR, against the normal ABI convention, you get inconsistent behavior calling from code which respects the normal wasm ABI. This is expected: an ABI mismatch is undefined behavior.
• The LLVM backend transforms "b & 1" to "-b" if b is known to be a sign-extended boolean. This is expected: it's optimizing based on the assertion that the value is in fact sign-extended.
• The handling of "signext" attributes in wasm calling convention lowering is slightly weird compared to other backends: for direct calls, most backends check both the declaration and the call, but wasm only checks the call itself. So declaring a function with a "signext" attribute, but not marking it on the call, leads to unexpected behavior. (https://godbolt.org/z/Kc7K3scon). Neither clang nor LLVM optimizations should generate code like this, though, so it generally shouldn't matter.

The last bullet-point is the only part that's arguably a bug. The rest is just misunderstandings about how the ABI works.