Stream: git-wasmtime

Topic: wasmtime / issue #3722 Cranelift: Sign/zero-extend docs d...

Wasmtime GitHub notifications bot (Jan 25 2022 at 02:49):

Mrmaxmeier opened issue #3722:

The docs for uextend and friends mention

If the input and output types are the same, this is a no-op.

When called with matching types, the verifier complains though:

https://github.com/bytecodealliance/wasmtime/blob/5fc01bafc7185b797f71c37352cbe66aa740893c/cranelift/codegen/src/verifier/mod.rs#L1471

Wasmtime GitHub notifications bot (Jan 25 2022 at 02:49):

Mrmaxmeier labeled issue #3722:

The docs for uextend and friends mention

If the input and output types are the same, this is a no-op.

When called with matching types, the verifier complains though:

https://github.com/bytecodealliance/wasmtime/blob/5fc01bafc7185b797f71c37352cbe66aa740893c/cranelift/codegen/src/verifier/mod.rs#L1471

Wasmtime GitHub notifications bot (Jan 25 2022 at 02:49):

Mrmaxmeier labeled issue #3722:

The docs for uextend and friends mention

If the input and output types are the same, this is a no-op.

When called with matching types, the verifier complains though:

https://github.com/bytecodealliance/wasmtime/blob/5fc01bafc7185b797f71c37352cbe66aa740893c/cranelift/codegen/src/verifier/mod.rs#L1471

Wasmtime GitHub notifications bot (Jan 25 2022 at 02:52):

Mrmaxmeier edited issue #3722:

The docs for uextend and friends mention

If the input and output types are the same, this is a no-op.

When called with matching types, the verifier complains though:

https://github.com/bytecodealliance/wasmtime/blob/5fc01bafc7185b797f71c37352cbe66aa740893c/cranelift/codegen/src/verifier/mod.rs#L1471

(Whoops, this probably shouldn't be labeled as a bug ^^)

Wasmtime GitHub notifications bot (Jan 25 2022 at 18:52):

fitzgen commented on issue #3722:

Thanks for filing an issue.

I'd be in favor of updating the docs to match reality, rather than changing the verifier. Thoughts @cfallin?

Wasmtime GitHub notifications bot (Jan 25 2022 at 19:12):

cfallin commented on issue #3722:

@Mrmaxmeier I'm actually somewhat surprised that a uextend-T-to-T didn't work; this line

if arg_type.lane_bits() >= ctrl_type.lane_bits() {

seems to indicate that equal input and output widths (>=) should be fine. I think that this is a reasonable thing to support; it simplifies the producer side not to have to special-case. Could you share the input that led to this error?

Wasmtime GitHub notifications bot (Jan 25 2022 at 20:04):

Mrmaxmeier commented on issue #3722:

The >= condition guards the error case. Here's a .clif:

target x86_64

function %func(i64) -> i64 {
block0(v0: i64):
    v1 = uextend.i64 v0
    return v1
}

Wasmtime GitHub notifications bot (Jan 25 2022 at 20:50):

cfallin commented on issue #3722:

Urgh, you're right, I didn't read closely enough; sorry!

I looked a bit more into whether the backends would already support this or not, and it appears that at least e.g. here in the x64 backend (maybe others too) the T-to-T case isn't handled. If you want to try your hand at doing so, I'm happy to review a PR, otherwise it's probably OK to update the docs to reflect the limitation for now. We might want to come back to this as we review opcode/type-coverage completeness, though.

Last updated: Nov 22 2024 at 17:03 UTC