Stream: git-wasmtime

Topic: wasmtime / issue #3361 Implement `VhighBits` & `Vselect` ...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 17 2021 at 15:56):

dheaton-arm commented on issue #3361:

Not sure what's causing the test failures as I can't seem to reproduce that locally (though that's using Ubuntu)...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 17 2021 at 16:23):

afonso360 commented on issue #3361:

This is what I see on CI.

 Caused by:
    0: Cranelift codegen error
    1: Verifier errors
    2: - inst2 (v0 = load.b8x16 v4): has an invalid controlling type b8x16

At a first glance i suspect it might be either #3306 or #3341.

I can investigate this a bit better later, but if it is #3306 it might be better to just rebase, if it is #3341 its a bit more complicated, since the solution on #3341 is wrong, and I am working on the correct solution using bmask, but its going to take a while...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 17 2021 at 16:26):

afonso360 edited a comment on issue #3361:

This is what I see on CI.

 Caused by:
    0: Cranelift codegen error
    1: Verifier errors
    2: - inst2 (v0 = load.b8x16 v4): has an invalid controlling type b8x16

At a first glance i suspect it might be either #3306 or #3341.

I can investigate this a bit better later, but if it is #3306 we might be able to solve this with a rebase, if it is #3341 its a bit more complicated, since the solution on #3341 is wrong, and I am working on the correct solution using bmask, but its going to take a while...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 17 2021 at 16:34):

afonso360 edited a comment on issue #3361:

This is what I see on CI.

 Caused by:
    0: Cranelift codegen error
    1: Verifier errors
    2: - inst2 (v0 = load.b8x16 v4): has an invalid controlling type b8x16

At a first glance i suspect it might be a trampoline compile failure, either #3306 or #3341.

I can investigate this a bit better later, but if it is #3306 we might be able to solve this with a rebase, if it is #3341 its a bit more complicated, since the solution on #3341 is wrong, and I am working on the correct solution using bmask, but its going to take a while...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 17 2021 at 16:48):

afonso360 commented on issue #3361:

Its not a trampoline compile failure. %vselect_p_i8x16 is failing the verifier after legalization. This is what comes out after the legalization pass (but before running the verifier).

function %vselect_p_i8x16(i64 ptr [%rcx], i64 ptr [%rdx], i64 ptr [%r8]) -> i8x16 [%xmm0] windows_fastcall {
                                block0(v4: i64, v5: i64, v6: i64):
[DynRexOp2fld#410]                  v0 = load.b8x16 v4
[DynRexOp2fld#410]                  v1 = load.i8x16 v5
[DynRexOp2fld#410]                  v2 = load.i8x16 v6
[DynRexMp3blend#910]                v3 = vselect v0, v1, v2
[Op1ret#c3]                         return v3
}

I'm not too familiar with the legalizer to be able to tell anything else.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 17 2021 at 17:01):

afonso360 edited a comment on issue #3361:

Its not a trampoline compile failure. %vselect_p_i8x16 is failing the verifier after legalization. This is what comes out after the legalization pass (but before running the verifier).

function %vselect_p_i8x16(i64 ptr [%rcx], i64 ptr [%rdx], i64 ptr [%r8]) -> i8x16 [%xmm0] windows_fastcall {
                                block0(v4: i64, v5: i64, v6: i64):
[DynRexOp2fld#410]                  v0 = load.b8x16 v4
[DynRexOp2fld#410]                  v1 = load.i8x16 v5
[DynRexOp2fld#410]                  v2 = load.i8x16 v6
[DynRexMp3blend#910]                v3 = vselect v0, v1, v2
[Op1ret#c3]                         return v3
}

I'm not too familiar with the legalizer to be able to tell anything else. This is weird to me because in #3306 we have tests receiving simd bool args, which don't get turned into load's, otherwise they would fail too.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 17 2021 at 17:03):

afonso360 edited a comment on issue #3361:

Its not a trampoline compile failure. %vselect_p_i8x16 is failing the verifier after legalization. This is what comes out after the legalization pass (but before running the verifier).

function %vselect_p_i8x16(i64 ptr [%rcx], i64 ptr [%rdx], i64 ptr [%r8]) -> i8x16 [%xmm0] windows_fastcall {
                                block0(v4: i64, v5: i64, v6: i64):
[DynRexOp2fld#410]                  v0 = load.b8x16 v4
[DynRexOp2fld#410]                  v1 = load.i8x16 v5
[DynRexOp2fld#410]                  v2 = load.i8x16 v6
[DynRexMp3blend#910]                v3 = vselect v0, v1, v2
[Op1ret#c3]                         return v3
}

I'm not too familiar with the legalizer to be able to tell anything else. This is weird to me because in #3306 we have tests receiving simd bool args, which don't get turned into load's, otherwise they would fail too. Is there something special about vselect?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 19 2021 at 14:45):

afonso360 commented on issue #3361:

It looks like this is only failing on the legacy backend. The test files pass if we remove the target x86_64 legacy haswell line.

Since bytecodealliance/rfcs#12 is approved, I think it would be ok if we disabled this test file for the legacy backend. Or we could wait a few more days until the FCP window is closed. @cfallin suggestions?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 21 2021 at 17:51):

cfallin commented on issue #3361:

Since bytecodealliance/rfcs#12 is approved, I think it would be ok if we disabled this test file for the legacy backend. Or we could wait a few more days until the FCP window is closed. @cfallin suggestions?

Yes, I agree, let's just exclude the old backend from this test.

Last updated: Dec 23 2024 at 13:07 UTC