Frank Emrich (May 23 2024 at 15:01): Frank Emrich (May 23 2024 at 15:01):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.
Afonso Bordado (May 23 2024 at 15:06):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 av128toI64X2caused 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
Frank Emrich (May 23 2024 at 15:51):Hi! Thanks for the answer and the pointer to the issue :smile:
Notification Bot (May 23 2024 at 15:51):Frank Emrich has marked this topic as resolved.
Last updated: Nov 22 2024 at 17:03 UTC