I was wondering to which degree cranelift treats i128
and the IiXj
types differently. For example, I've noticed that cranelift refuses to use the former in parameter/return types, unless enable_llvm_abi_extensions
is set (which seems to be incompatible with how wasmtime wants to use cranelift). Does the choice between the two kinds of types actually affect the generated code, such as the registers used, how they are passed as parameter/return values (assuming the setting I mentioned earlier is enabled), etc? Of course there is a difference between the CLIF instructions that can actually operate on these types.
Part of the reason I'm asking is that I ran into a problem where bitcast
-ing a v128
to I64X2
caused a panic during lowering, despite the CLIF verifier being happy with the bitcast
.
Hey! Yes, it does. In most architectures vectors will be stored in vector registers, and not in integer registers. i128
's will usually be stored in two 64 bit registers instead of vector registers.
There are also abi concerns, that dictate how these two values are passed. And that will also usually change between vectors and i128's.
Part of the reason I'm asking is that I ran into a problem where
bitcast
-ing av128
toI64X2
caused a panic during lowering, despite the CLIF verifier being happy with thebitcast
.
This is unfortunately a known issue (#6104). It should be legal CLIF, and there is nothing wrong with it. It's just that we don't have that instruction sequence implemented in the backend.
A workaround for this would be to create a stack slot, and store the i128
, and then load it back as i64x2
Hi! Thanks for the answer and the pointer to the issue :smile:
Frank Emrich has marked this topic as resolved.
Last updated: Dec 23 2024 at 12:05 UTC