Stream: git-wasmtime

Topic: wasmtime / issue #3276 Cranelift: Signed SIMD vectors are...

Wasmtime GitHub notifications bot (Sep 01 2021 at 16:28):

dheaton-arm opened issue #3276:

Various opcodes (such as SaddSat) only make sense if SIMD vectors can contain negative values, however the IR parser raises an error if a negative immediate is supplied, requiring explicitly u8 decimal immediates.

By supplying the 2's complement of the negative value in a SIMD vector, converting the values lanewise to signed values, and then performing a signed operation on the converted values, the correct results can be achieved (albeit again returned as the 2's complement, as unsigned values).

I would think given the existence of opcodes that rely on signed SIMD vectors, signed immediates should be allowed. Perhaps an unsigned variant (eg, u64x2) of each vector would make sense? These unsigned variants could behave as the current SIMD implementation does, but i64x2 could behave as a vector of signed values, instead.

Wasmtime GitHub notifications bot (Sep 01 2021 at 16:35):

bjorn3 commented on issue #3276:

Adding u64x2 would require adding u64 too. Cranelift IR currently doesn't distinguish between unsigned and signed integers, only between unsigned and signed instructions, with many instructions working on both due to the way 2s-complement works. I would like it to stay this way.

I think it would be better to allow both unsigned and signed immediates just like for scalar operations.

Wasmtime GitHub notifications bot (Sep 01 2021 at 17:51):

afonso360 commented on issue #3276:

We discussed this somewhat in #3059, not specifically for SIMD, but allowing a range of negative and positive integers based on the size of the type. I think it would also make sense to apply those same rules for the lane type in SIMD consts.

I agree with @bjorn3, keeping a single type, but allowing signed and unsigned immediates seems like the best way to go about this.

Wasmtime GitHub notifications bot (Sep 02 2021 at 09:42):

dheaton-arm commented on issue #3276:

If the un/signed distinction occurs based on the instruction, then that makes sense.

Wasmtime GitHub notifications bot (Sep 02 2021 at 14:52):

dheaton-arm commented on issue #3276:

Hi, sorry, after further testing, it turns out my description of this isn't entirely correct anyway. The problem here lies solely in i8x16 vectors, as the parser specifically checks for u8 immediates in vectors; if this is incorrect behaviour anyway, I'm happy to try fix that, but I wanted to check first if there was a specific reason for it. i16x8 and above do support signed values.

Wasmtime GitHub notifications bot (Sep 02 2021 at 17:12):

abrown commented on issue #3276:

I think it is reasonable to parse i8x16 as lanes of i8--I can't recall precisely why u8 was used but it may have just been because it was available and i8 parsing was not. Adding i8 parsing makes sense to me.

Wasmtime GitHub notifications bot (Sep 03 2021 at 16:48):

cfallin closed issue #3276:

Various opcodes (such as SaddSat) only make sense if SIMD vectors can contain negative values, however the IR parser raises an error if a negative immediate is supplied, requiring explicitly u8 decimal immediates.

By supplying the 2's complement of the negative value in a SIMD vector, converting the values lanewise to signed values, and then performing a signed operation on the converted values, the correct results can be achieved (albeit again returned as the 2's complement, as unsigned values).

I would think given the existence of opcodes that rely on signed SIMD vectors, signed immediates should be allowed. Perhaps an unsigned variant (eg, u64x2) of each vector would make sense? These unsigned variants could behave as the current SIMD implementation does, but i64x2 could behave as a vector of signed values, instead.

Last updated: Dec 23 2024 at 12:05 UTC